Method and apparatus for performing raw cell status report frequency mitigation on receive in a network node

ABSTRACT

A mechanism for mitigating the rate at which status reports associated with raw cell data transfers occur during receive operations in a network node is presented. The network node has an adapter for coupling a network and a host system, the host system including a host memory. The adapter operates to reassemble cell data received from the network and store the reassembled cell data in the host memory. A raw report holdoff counter is programmed to count a number corresponding to a preselected rx raw report holdoff value. If a raw cell data transfer request to be processed is detected, rx raw report information necessary to creating an rx raw cell status report is copied to a temporary storage area. When the data is transferred to the host system, the raw report holdoff counter is modified by one. When the modified counter has expired, the rx raw report information is written to a report queue in host memory.

FIELD OF THE INVENTION

The invention relates generally to an end node in a high performancecomputer system or network, such as an ATM network, and moreparticularly, to a method and apparatus for improving the performancelevel of the end node by reducing system overhead and maximizing busbandwidth utilization.

BACKGROUND OF THE INVENTION

A large part of the cost of networking is the cost of moving databetween a host computer system and a network. Under conventionalapproaches, systems buffer network data in host memory buffers, whichare sometimes chained into linked lists. Buffer chaining is typicallyemployed in systems utilizing “scatter-gather” techniques. For example,when the host system needs to transmit a data packet stored in buffersto a network via a network interface or adapter, it makes available tothe network adapter control information associated with each buffer. Thecontrol information may include, among other buffer-related information,a pointer to a buffer of data and the length of the buffer. The chain ofbuffers is passed to the appropriate host system protocol stack, wherethe chain is augmented with the appropriate headers, and subsequently,to the driver for transmission. The driver then instructs the networkadapter to copy the buffer data into the network interface's localmemory and transmit the packet onto the network. The adapter must thenparse the linked lists in gathering the various host memory buffersassociated with the packet to be transmitted and copy the buffers intothe local memory. One known technique for copying the buffer data fromhost memory to network adapter local memory without involving the hostCPU is direct memory access (DMA).

In an alternative approach, commonly referred to as “programmed I/O”,the data copying is performed by the host CPU. During a transmitoperation, the host CPU reads the address of an available adaptertransmit buffer, writes the available transmit buffer with packet headerand application data, and then writes the associated control informationinto a buffer. Once the adapter transmits the packet data onto thenetwork, the freed buffer address is placed back in the transmit bufferand is returned to the host CPU. A receive operation functions in asimilar manner. Incoming packets are queued in a receive buffer. Uponreceiving an interrupt, the host CPU reads the buffer address and thecontents of the buffer corresponding to the address, and subsequentlyreturns the buffer address to the adapter to be re-used.

Because the system bus must be utilized in every host-adapter operationperformed by a computer system, its characteristics and utilization havea major impact on the overall performance of the system. It can beobserved that, in the aforementioned system implementations, controlcommunications as well as data transfers take the form of both read andwrite transactions. Because of the added latencies associated with readaccess times (i.e., turnaround address-to-data time), a high ratio ofread transactions to write transactions can adversely impact system busand therefore overall system performance. Bus performance is furtherdegraded by the number of control transactions, since controltransactions consume bus bandwidth, thereby reducing the bandwidthavailable for data movement. Both transmit and receive throughput isadversely affected by lower levels of system bus bandwidth availabilityand high control/data overhead; consequently, the overall throughputrate is lower. The impact of control transactions becomes even morepronounced in systems transmitting and receiving a great number ofsmaller packets, because of the higher control/data overhead associatedwith such smaller packets. Thus, it can be seen that controlcommunications, and more specifically, control read transactions, do notmake efficient use of the system bus.

Another problem encountered in high performance systems, and morespecifically, those high performance systems which employ a burst modetype of system or local bus, is the inability to burst write data to asingle location, such as a data FIFO. Burst mode buses, such as the PCIbus, do not allow a burst access to a single address location. Instead,the accesses must appear on the bus as separate and distincttransactions. Again, overall performance suffers.

System performance can also be adversely affected by other host-adapterinteractions, such as interrupts and reporting operations. Interruptsoccur when a device like a network interface signals the host toindicate that the device needs to be serviced. In a typical networkinterface application, the host may be interrupted for a variety ofreasons. For example, the adapter may generate an interrupt and a reportto the host when a data packet to be transmitted has been transferred bya DMA operation from host memory to adapter local memory. An interruptand report may also occur when an incoming data packet has beentransferred from the adapter to the host memory. The cost of suchinteractions can be significant. Moreover, in the case of smallerpackets or cells, such as ATM raw cells, for which little data copyingis done, these other interactions often represent most of the cost ofsending a packet. Thus, it may be undesirable to report status andinterrupt the host on a per-cell basis.

Therefore, there exists a clearly felt need in the art for a mechanismwhich provides for high bus bandwidth utilization and low-latencycontrol communications between a host computer and a high performanceperipheral, such as an ATM network adapter. Further, there is a need tosuppress or minimize the frequency of interrupt requests and reportsqueued to the host system.

SUMMARY OF THE INVENTION

Accordingly, there is provided a method and corresponding apparatus formitigating the frequency with which status reports associated with rawcell data transfers occur during receive operations in a network node.The network node has a network and a host system including a host memorycoupled to the network by an adapter. The adapter reassembles cell datareceived from the network and stores the reassembled cell data in thehost memory. The method of the present invention begins by programming araw report holdoff counter to count a number corresponding to apreselected rx raw report holdoff value. If a raw cell data transferrequest to be processed is detected, rx raw report information necessaryto creating an rx raw cell status report is copied to a temporarystorage area. The method performs the data transfer of the raw cell datato the host system and modifies the raw report holdoff counter by one.If the modified counter has expired (i.e., counted a numbercorresponding to a preselected rx raw report holdoff value), the rx rawreport information is written to a report queue in host memory and theraw report holdoff counter is reloaded. If the modified raw reportholdoff counter has not expired, then the method returns to the step ofdetecting a raw cell data transfer request to be processed.

BRIEF DESCRIPTION OF THE DRAWINGS

An embodiment of the invention will be described with reference to theaccompanying drawings, in which:

FIG. 1 is a block diagram of a system having a host system connected toa network via an adapter;

FIG. 2 depicts the format for an ATM cell;

FIG. 3 is block overview of the adapter of FIG. 1;

FIG. 4 is a top-level functional block diagram of the SAR controller inthe adapter of FIG. 3;

FIG. 5 illustrates a classical IP packet residing in the host memory ofthe host system shown in FIG. 1;

FIG. 6 is a block diagram of the segmentation engine of the SARcontroller shown in FIG. 4;

FIG. 7 illustrates the organization of the local memory shown in FIGS.3;

FIG. 8A is a block diagram showing the host system, PCI bus, PCI businterface and the tx pending slot FIFO, the block diagram serving toillustrate the tx pending slot controller in the PCI bus interface;

FIG. 8B is a timing diagram of a PCI bus burst write transaction;

FIG. 9 is a flow diagram depicting a method used by the tx pending slotcontroller 186 of FIG. 8A for performing a burst write of data to the txpending slot FIFO;

FIG. 10 illustrates the layout of a tx pending slot FIFO entry in the txpending slot FIFO;

FIG. 11 is a depiction of the tx active slot lists residing in controlmemory on the adapter of FIG. 2;

FIG. 12 is a depiction of the tx free slot list in the local memory onthe adapter of FIG. 2;

FIG. 13 shows the format of the active slot list entry in the activeslot lists;

FIG. 14 is a layout of the transmit VC state table in the local memory;

FIG. 15 illustrates the format of an AAL5 packet carrying two MPEGprotocol data units (PDUs);

FIGS. 16a-b are block diagrams of the tx data FIFO of FIG. 6, inunsegmented and segmented mode respectively;

FIG. 17 is a block diagram of the fifo_remain controller of FIG. 6;

FIG. 18 is a flow diagram of the operation of the fifo_remain counter ofFIG. 17;

FIGS. 19a-c illustrate the three types of tx DMA request FIFO entries:Data DMA request entry (FIG. 19a), Idle Slot Report Request Entry (FIG.19b) and RM Cell Request Entry (FIG. 19c);

FIG. 20a is a detailed block diagram of the schedule table and VC listof FIG. 6;

FIG. 20b is a block diagram of a worklist utilizing the VC list shown inFIG. 20a;

FIG. 21 is a high level flow diagram showing the operation of the txrate scheduler and tx DMA scheduler FSMs of FIG. 6;

FIGS. 22a-j show a detailed flow diagram of the operation of the tx ratescheduler FSM of FIG. 6;

FIGS. 23a-f show a detailed flow diagram of the operation of the tx DMAscheduler FSM of FIG. 6;

FIG. 24 illustrates a tx data synch FIFO SOC control longword;

FIGS. 25a-b show a detailed flow diagram of the operation of the tx DMAFSM of FIG. 6;

FIG. 26 is a block diagram illustrating the tx data FIFO of FIG. 6holding three entries;

FIG. 27 illustrates a tx data FIFO SOC control longword;

FIGS. 28a-d is a detailed flow diagram of the operation of the tx cellFSM of FIG. 6;

FIG. 29 is a block diagram of the tx data FIFO and tx phy FSM of FIG. 6;

FIGS. 30a-d show a detailed flow diagram of the operation of the tx phyFSM of FIG. 6;

FIG. 31 illustrates the layout of a tx report queue entry of the txreport queue of host memory (FIG. 1);

FIG. 32 is a flow diagram of a method of performing tx raw cell reportfrequency mitigation;

FIG. 33 is a flow diagram of a method of reporting status for data otherthan raw cell data;

FIG. 34 illustrates an AAL5 packet stored in three rx slots;

FIG. 35 is a block diagram of the reassembly engine of the SARcontroller;

FIG. 36 illustrates in rx pending slot FIFO entry of the rx pending slotFIFO of the reassembly engine;

FIG. 37 depicts the format of a rx VC state table entry;

FIG. 38 is an illustration of the rx data FIFO;

FIGS. 39A-C illustrate the formats for the three types of Rx Cell SODentries: rx data AAL5 Cell SOD entry (A), rx data raw cell SOD entry (B)and rx AAL5 status report SOD entry (C);

FIG. 40 illustrates the format of an rx raw cell status longword;

FIGS. 41A and 41B depict the rx AAL5 and raw cell report queue entries,respectively, of the rx report queue shown in host memory (FIG. 1);

FIG. 42 shows the rx_raw_report_hldoff field in the SAR_Cntrl2 registerCSRs.

FIG. 43 is a flow diagram illustrating a method of performing rx rawcell status report frequency mitigation.

FIG. 44 shows the layout of the rx_slot_cong_th register in CSRs;

FIG. 45 is a flow diagram showing the rx congestion control methodperformed by the SAR controller in conjunction with the driver.

FIG. 46 depicts the layout of the INT CSRs from FIG. 4;

FIG. 47 is a flow diagram of the interrupt-on-completion interruptrequest frequency mitigation method.

FIG. 48 illustrates the interrupt block and the PCI bus interfacesignals involved in IOC interrupt request generation;

FIG. 49 shows the system from FIG. 1 having a host system coupled to aperipheral unit by an interface;

FIG. 50 depicts the format of the message type field of an RM cell; and

FIG. 51 is a logical representation of the generation of the CI bit in abackwards RM cell header.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring to FIG. 1, there is illustrated a system 10, which includes anadapter 12 coupled to an end-system shown as a host system 14 and anetwork 16. The host system 14 and adapter 12 each are connected to andcommunicate with one another over a system bus 18. The adapter 12 isconnected to and directly interfaces with the network 16. The hostsystem 14, system bus 18 and adapter 12 in the illustrated configurationthus represent a “network” node 19. This type of network node is anend-system network connection, sometimes referred to as an “end” node.

In pertinent part, the host system 14 includes a central processing unit(CPU) 20 coupled to a host memory 22. The host memory includes a driver24 and a buffer memory 26. A user application 28 (executing in the CPU20) provides, via networking software layers (not shown), network-bounduser data to the driver 24 as protocol data units (PDUs).

In the illustrated embodiment, the buffer memory 26 includes transmit(tx) slots 30 and receive (rx) slots 32. The driver utilizes the txslots 30 to store the PDUs awaiting transmission. The rx slots 32 areused to store data received from the network 16 via the adapter 12.

Further included in the host memory are report data structures 34 forstoring status reports provided to the host system 14 by the adapter 12.The report data structures include a transmit (tx) report queue 36 and areceive (rx) report queue 38. Additionally, there is provided in thehost memory a lookup table 40 for physical-to-virtual address mapping.

Now referring to FIG. 3, there is shown a preferred implementation ofthe adapter 12 (from FIG. 1) as an Asynchronous Transfer Mode (ATM)adapter. Because the description of this embodiment contains numerousacronyms and terms that are associated with ATM, the description of theadapter 12 in FIG. 3 follows a very brief discussion of ATM networks.Additional information can be had with reference to “ATM User-NetworkInterface Specification, Version 3.1”, and other documents published bythe “ATM Forum”.

An ATM network is a cell-based network in which fixed-length cellsrelating to different media are statistically multiplexed together andhave random time intervals between them. The ATM cells are transmittedin slots in the payload of, e.g., the frames of a SONET signal.

ATM messages move through the network over virtual circuits (VCs), whichare set up by and established between the end nodes in the network. Eachmessage in an ATM network is made up of one or more of the fixed-lengthcells. Referring to FIG. 2, an ATM cell 42 is shown to be 53 bytes long.The ATM cell 42 is typically divided into a 5-byte header 44 and a48-byte payload 46. As shown, the ATM header 44 includes the following:a generic flow control field 48, a virtual path (VPI) identifier 50, avirtual channel identifier (VCI) 52, a payload type identifier (PT)field 54, and a cell loss priority (CLP) field 56. The ATM header 44further includes a header error control (HEC) field 58. The GFC field 48is used to ensure that users are given fair access to transmissionfacilities. The VPI 50 identifies a virtual path between two nodes. Thevirtual path is simply a collection of channels associated with the sameuser endpoint. The VCI 52 identifies a virtual channel between twonodes. A virtual channel is a unidirectional virtual circuit (VC)associated with a particular user. The PT field 54 is used todifferentiate between cells carrying user data and cells carrying ATMcontrol information, such as OAM cells. The CLP field 56 indicates theeligibility of a cell being discarded during a period of congestion. TheHEC field 58 is used to detect corruption of the information containedin the ATM header 44. The payload field 46 contains the data portion ofa cell.

Referring now to FIG. 3, the adapter 12 includes a Segmentation andReassembly (hereinafter referred to as simply “SAR”) controller 62,which interfaces directly to the system bus 18. In this embodiment, thesystem bus 18 is a 32-bit PCI bus with Universal I/O. The SAR controller62 is connected to a crystal oscillator 64, which provides a timingsource for the SAR controller, as well as one or more adapter-residentdevices indicated as peripheral devices 66 via a peripheral bus 68. Theperipheral devices 66 include (but are not limited to) LEDs, MAC addressPROM and PCI subsystem ID registers.

The SAR controller 62 is further connected to a PHY device 70, whichimplements the ATM physical layer. As shown, the PHY device 70 includesa Transmission Convergence (TC) sublayer device 72 and a Physical MediaDependent (PMD) sublayer device 74. The TC sublayer device 72 definesline coding, scrambling, data framing and synchronization. The PMDsublayer device 74 typically includes the functions for transmitter,receiver and timing recovery that allow connection to the transmissionmedia of the network 16, also referred to as the network bus 16. In theembodiment of the invention illustrated in FIG. 3, the network bus 16 isindicated as being of the SONET STS-3c/STM-1 type. The SONETSTS-3c/STM-1 transmission rate is specified to be 155.52 Mb/s. It can beseen from the figure that peripheral bus 68 also provides access to PHYlayer devices (not shown) in the PHY device 70.

Additionally, the adapter includes a local memory 76, which is connectedto the SAR controller 62 and provides storage for numerous datastructures utilized by the SAR controller 62 and the host system 14(from FIG. 1) for various key functions. In this embodiment, the localmemory 76 supports 1K VC mode memory requirements. The internalorganization of the local memory 76 and the different data structurescontained therein will be described in detail later.

FIG. 4 is a top-level diagram illustrating the general architecture ofthe SAR controller 62. The SAR controller 62 has three interfaces thatinclude the following: a PCI bus interface 78 with a 32-bit wide databus, a PHY interface 80 and a peripheral bus interface 82.

The PCI bus interface 78 connects the SAR controller to the PCI bus 18,and therefore couples the SAR controller 62 to the host system 14 viathe PCI bus 18. Although not shown in FIG. 1, the host system 14 mayinclude a PCI bus interface or PCI bridging logic, depending on theconfiguration of the host system and whether the PCI is serving as alocal or system bus. The SAR controller 62 masters the PCI bus in itsmaster mode and allows the host system 14 to access the SAR controller62 in slave-mode operation. The PCI bus interface 78 implements a 32-bitdata buffer to provide a data path to and from the host system. Thisblock also includes PCI configuration space registers (not shown).

On the line-side of the SAR controller 62, the PHY interface 80implements the industry-standard UTOPIA data path handshake protocol inconformance with the UTOPIA interface specification. The UTOPIAinterface consists of an 8-bit wide data path and associated controlsignals in both the tx and rx directions. Consequently, ATM cells passbetween the ATM and PHY layers through the UTOPIA interface.

Although not shown, the SAR controller 62 may also be connected directlyto devices implementing the ATM layer of the UTOPIA specification (asopposed to the PHY layer) through a Reversible UTOPIA mode of operation.In Reversible UTOPIA mode, the SAR controller 62 acts as the UTOPIA PHYlayer at the line-side interface. This is particularly useful in ATMswitch applications, where the SAR controller 62 may be connected to theswitch fabric through the same mechanism as all other ports in theswitch.

The peripheral interface 82 is connected to the PCI bus interface 78.Through the peripheral interface 82, the host system may access thevarious on-adapter peripheral devices. As al ready mentioned, theseperipheral devices may include a MAC address PROM and LEDs, as well asPCI subsystem and subsystem vendor ID registers. Additional devicescould include error-logging EPROM and CSRs in the PHY device. In theembodiment of the present invention, the peripheral interface 82directly supports a 64KB address space and an 8-bit wide data path.

The SAR controller 62 also includes a clock generation block 84, whichgenerates and distributes clock signals to the various components of theSAR controller 62, and a number of internal control and status registers(CSRs), which are shown in FIG. 3 as CSRs 86. The CSRs 86 are coupled tothe PCI bus interface 78, a segmentation engine 88 and a reassemblyengine 90. As shown in the figure, the CSRs include interrupt CSRs 92,which are coupled to an interrupt logic block 94. Together, theinterrupt CSRs 92 and interrupt logic block 94 compose an interruptblock 96 (indicated in dashed lines).

An address map for the CSRs 86 is provided in Table 1 below.

TABLE 1 CSR Read/Write LW Address Default Tx_Pending Slots WO 0 × 0-0 ×F N.A. Rx_Pending Slots WO 0 × 10-0 × 1F N.A. SAR_Cntrl1 RW 0 × 2000000040 SAR_Cntrl2 RW 0 × 21 00001001 Intr_Status RW1C 0 × 22 00000000Intr_Enb RW 0 × 23 00000000 Intr_Hldoff RW 0 × 24 00000000Tx_FS_List_Ptrs RW 0 × 25 00000000 Tx_Report_Base RW 0 × 26 00000000Rx_Report_Base RW 0 × 27 00000000 Tx_Report_Ptr RO 0 × 28 00000000Rx_Report_Ptr RO 0 × 29 00000000 Rx_Slot_Cong_Th RW 0 × 2A 00000000Tx_ABR_ADTF RW 0 × 2B 00000000 Tx_ABR_Nm_Trm RW 0 × 2C 00000000Peephole_Cmd RW 0 × 2D 40000000 Peephole Data RW 0 × 2E 80000000Rx_Raw_Slot_Tag RO 0 × 2F 00000000 Rx_CellCnt RO 0 × 30 00000000Rx_AAL5_DropPKTCnt RO 0 × 31 00000000 Rx_Raw_DropCellCnt RO 0 × 3200000000 Tx_CellCnt RO 0 × 33 00000000 Real_Time RO 0 × 34 00000000Current_Time RO 0 × 35 00000000 Test_Cntrl RW 0 × 36 00000000 NOTES: RW= Read/Write RW1C = Read/Write-one-to-clear RO = Read only WO =Write-only

Because the local memory and peripheral devices external to the SARcontroller are not memory-mapped, there is needed a means by which thehost system can access these areas. Two of the CSRs, the Peephole_Cmdand the Peephole_Data registers, provide a mechanism which allows thehost system to access local memory using address space available througha local memory interface (not shown) or peripheral devices using addressspace available through the peripheral interface. For a readtransaction, for example, the host system writes a device address (inthe partitioned address space) to the Peephole_Cmd register and usesother bits in the register to indicate the type of access and select thetype of device to be read as either a peripheral device or SRAM. It thenpolls the Peephole_Data register for an indication that the operationhas been completed. Once that indication is given (i.e., setting of bitin data register), the returned data can be read from the register.Because this mechanism is well known in the art, further details are notprovided. The operational functions provided by other CSRs are referredto and discussed in more detail later.

The primary function performed by the SAR controller 62 is thesegmentation and reassembly of CPCS-PDUs. Referring again to FIG. 4, theSAR controller 62 receives packet information over the PCI bus throughthe PCI interface 78. Connected to both the PCI interface 78 and the PHYinterface 80, as well as the adapter's local memory 76 (from FIG. 3) isthe segmentation engine 88 and a reassembly engine 90. Collectively, thesegmentation engine 88 and the reassembly engine 90 implement the SARfunction as described in the ATM User-Network Interface Specification,Version 3.1.

In the transmit direction, the SAR controller 62 receives from thedriver 24 (shown in FIG. 1) complete AAL5 CPCS-PDUs, each including a4-byte AAL5 CRC placeholder. The Pad, Control and Length fields providedby the driver must be correct, and are not checked by the SARcontroller. In contrast, the AAL5 CRC need not be correct. Thesegmentation engine 88 segments the AAL5 PDUs into fixed length ATMcells, appends cell headers to each ATM cell created by the segmentationprocess, computes AAL5 CRCs, and overwrites the placeholder CRCs withthe computed CRCs in the transmitted PDUs. Segmentation and transmissionof up to 1K AAL5 PDUs simultaneously is supported.

In the receive direction, the reassembly engine 90 reassembles the AAL5PDUs and can reassemble up to 1K AAL5 PDUs simultaneously. In addition,the engine calculates and verifies the AAL5 CRC and length fields ofreceived AAL5 CPCS-PDUs.

With respect to the embodiment described herein, a VC opened fortransmission and reception of data is defined to be in one of 3 classes:constant bit rate (CBR), and variable bit rate which may be eitheravailable bit rate (ABR) or unspecified bit rate (UBR). CBR circuitshave a fixed cell transmission rate which is specified at signaling timeand does not change thereafter. ABR circuits are subject to therate-based flow control mechanisms specified by the Traffic Managementspecification of the ATM Forum. The allowed cell transmission rate forsuch a circuit will therefore vary over time. UBR circuits have a fixedpeak cell rate which is also specified at signaling time and does notchange thereafter. The SAR controller guarantees that this peak cellrate will not be exceeded under any condition, but it does not guaranteethat this rate will be met.

The SAR controller 62 also implements the Generic Flow Control protocolas defined in ITU-T SG 13 Revised version documents I.361-TD41 andI.150-TD42 November 1994 Geneva. GFC is a one-way, link-level flowcontrol scheme for controlling the flow of data into an ATM network. Inthe GFC protocol, the ATM connections are divided into two categories:controlled and uncontrolled. When a cell is received with the HALT bitset in the GFC field 48 in the cell header 44 (FIG. 2), all transmittraffic is halted. When a cell is received with the SET_A bit reset(=0), controlled traffic is halted, while uncontrolled traffic may betransmitted. As implemented herein, all CBR VCs are uncontrolled, whileABR and UBR VCs are controlled.

Also supported is credit-based flow control. There are a number ofwell-known credit-based flow control schemes; thus, a description ofcredit-based flow control is not provided herein, but can be had withreference to a paper by Cuneyt M. Ozveren, Robert Simcoe and GeorgeVarghese, entitled “Reliable and Efficient Hop-by-Hop Flow Control”,IEEE Journal on Selected Areas in Communications. May 1995, pp. 642-650.

The SAR controller 62 supports up to 1K Virtual Circuits (VCs)simultaneously, in both the receive and transmit directions. Therefore,as many as 1K AAL5 PDUs may be segmented and transmitted simultaneously(1K-way interleaving of AAL5 PDUs on the link), while 1K AAL5 PDUs arebeing simultaneously received and reassembled.

In addition to implementation of the AAL5 adaptation layer, the SARcontroller 62 provides support for other adaptation layers via “raw”52-byte cells and provides for the segmentation of MPEG “super-packets”into multiple 8-cell AAL5 packets. Related support is provided for theinsertion of “idle packets” in order to achieve exact rates and reducethe amount of buffering needed, for example, at a set-top box. MPEGsuper-packet segmentation is selected on a per-VC basis, and idle packetinsertion is done on a per-packet basis, where idle packets may consistof any number of cells.

ATM is fundamentally a full-duplex technology and thus the transmit andreceive operations of SAR controller 62 can be viewed as largelyindependent operations. Therefore, each operation is discussedseparately in the description to follow.

Hereafter, it is assumed that a sufficient amount of local memory (e.g.,128 KB SRAM) to support 1K transmit and receive VCs is present on theadapter 12. The term “longword” (LW) refers to a 4-byte unit of data.The term “word” (W) refers to a 2-byte unit of data. The transmit (tx)or outgoing direction of data flow refers to data flowing from hostmemory, into the SAR controller 62, and onto the network 16. The receive(rx) or incoming direction of data flow refers to data flowing from thenetwork 16, into the SAR controller 62, and then into host memory 22.The word “packet” (or, alternatively, the acronym “PDU”) as used hereinrefers to either AAL5 CPCS-PDUs or raw cells. Raw cells are defined ascells which are not part of an AAL5 CPCS-PDU. For example, they may beF4 or F5 OAM cells, ABR RM cells, or cells for an AAL other than AAL5.It should be noted that tx RM cells are generated by the SAR controlleritself. Further, there are many FIFOs and linked lists employed in thearchitecture of the SAR controller. In the described embodiment, entriesfor these types of data structures are written to the tail of thestructure, and read from the head, unless explicitly set forthotherwise. References to elements in the various link lists to bedescribed are set forth in the format “A[B]:C” wherein A is the list, Bthe index into the list, and C the field in the element indexed.

Transmit Operation

Returning to FIG. 1, the driver 24 of the host system 14 places userdata contained in a packet received from the user application 28 intoone or more of the tx slots 30 in host memory 22 in order to begin thetransmission of the packet. Each tx slot 30 is a block of memory in aphysically contiguous area in host memory 22. A single AAL5 packet maybe contained in a single tx slot, or may span many tx slots 30. Each rawcell must be contained in a single tx slot 30. Although the tx slots 30are depicted as being of uniform size, their size can in fact vary. Txslots containing portions of an AAL5 PDU may vary in size from 1 byte to16 Kbytes, with 1-byte granularity, while tx slots containing raw cellsare exactly 52 bytes long. The first byte of a raw cell or AAL5 packetoccupies the lowest byte address of a tx slot. A single tx slot cancontain at most one AAL5 packet or raw cell. Tx slots 30 may be locatedat any byte address in host memory 22, although optimal performance isobtained when the starting address of each slot is longword-aligned.Also, for best performance, slots should generally be as large aspossible, with the optimal case being a one-to-one correspondencebetween packets and tx slots.

Each AAL5 packet posted for transmission contains the AAL5 pad (0 to 47bytes), Control (2 bytes), Length (2 bytes) and CRC placeholder (4bytes) fields. The SAR controller 62 will compute the correct AAL5 CRCand overwrite the placeholder CRC when transmitting the packet.

FIG. 5 depicts a classical Internet Protocol (IP) packet 98 to betransmitted on the link as it may appear in host memory when occupyingfour tx slots. As shown, slot 1 100 contains 8 bytes of SNAP headerinformation. Slots 2 (102) and 3 (104) contain IP SDU data. These userdata slots may be different sizes. IP pad information occupies slot 4(106).

The driver 24 may allocate as much host memory 22 as it wishes for txslots, and any number of tx slots may be in use by the driver 24 at anypoint in time. In the embodiment shown in the figures, the SARcontroller 62 only limits the total number of slots from which it may bereading data for transmission at any one point in time to the number offlows which it supports. In the described embodiment, a “flow” is a VC;however, other types of flows can be utilized without departing from thespirit of the inventive concepts described herein. An example of analternative type of flow is a stream of packets between a pair of nodesin a datagram network.

Once the driver has placed data for one or more packets across one ormore VCs in tx slots 30 in host memory 22, it must indicate to the SARcontroller 62 the location of the tx slots 30 and the VCs with whicheach slot is associated. In order to post a single slot fortransmission, the driver writes control information to an address space(see Tx_Pending Slots in CSRs shown in Table 1) in the SAR controller.In this embodiment, the control information is 2 LWs long. The addressspace is hereafter referred to as the “tx pending slots” address space.When the driver writes 2 consecutive LWs of control information to thisaddress space, the operation is referred to as posting a tx slot. Notethat the 2 LW writes are not required to occur in a single PCI burst;the SAR controller can handle an arbitrarily long delay between thewrite of the first and the second LWs corresponding to the posting of asingle tx slot. The tx pending slot address space is 16-LW deep in orderto allow the posting of up to 8 tx slots in a single 16-LW PCI burst.

Referring to FIG. 6, there is shown the major functional components ofthe segmentation engine 88 of the SAR controller 62. A tx rate schedulerFSM 120 is coupled to a tx DMA scheduler FSM 122, worklist pointers 123and the local memory 76. The tx DMA scheduler FSM 122 is coupled to a txpending slot FIFO 124, a tx DMA request FIFO 125, and the local memory76. A tx DMA FSM 126 is coupled to the PCI interface 78, to the tx DMArequest FIFO 125, and to a tx cell FSM 130. A tx data synch FIFO 128 iscoupled to the tx DMA FSM 126, to the tx cell FSM 130, to a tx data FIFO132, and to a tx phy FSM 134. The tx phy FSM 134 is coupled back to therate scheduler FSM 122.

Also shown is the adapter-resident local memory 76 (from FIG. 3).Although the local memory is not part of the SAR controller 62 in theillustrated ATM adapter of FIG. 3, it is utilized by the SAR controller62 during a transmit operation and thus included in the figure. Althoughsome of the data structures in the local memory are used during areceive operation, it is necessary to discuss briefly the various datastructures contained within the local memory at this point.

An example of the internal organization of the local memory 76 in itsentirety is provided by FIG. 7. FIG. 6 illustrates only those datastructures that relate to a transmit operation. With reference to bothFIGS. 6 and 7, the local memory 76 includes the following control datastructures: rx free buffer memories 139, implemented as FIFOs and thusalternatively referred to as rx free slot FIFOs 139, preferablyincluding an rx AAL5 big free slot FIFO 140, an rx AAL5 small free slotFIFO 141 and an rx raw cell free slot FIFO 142; an rx slot_tag VC statetable 144; VC state tables 146 preferably including a tx VC state table148 and a rx VC state table 150; an ABR parameters table 152; an ABRvalue table 154; an RM cell table 156; tx slot descriptors 160, whichincludes a tx free slot list 161 and active slot lists 162 (both shownin FIG. 6); an ACR lookup table 164; rx AAL5 big_slot_tags 168, rx AAL5small_slot_tags 170, and rx raw_slot_tags 172; a schedule table 174including a ABR schedule table 176 and an ABR schedule table 178; and VCList 180. Two reserve fields are also provided, and are indicated byreference numbers 179 and 180. Referring to FIG. 6 only, the combinationof the tx pending slot FIFO 124, the tx free slot list 161 and the txactive slot lists is depicted as and referred to as a tx control memory181. Many of these structures will be discussed in detail with referenceto the transmit and/or receive operations.

When the above-mentioned control information is written by the hostsystem 14 to the tx pending slot address space, it is placed in the txpending slot FIFO 124 by the PCI bus interface 78 operating in PCI slavemode. In keeping with the embodiment thus described, the tx pending slotFIFO 124 is 8 entries deep. Each time a set of 2-LW writes occurs to thetx pending slot address space (i.e., each time the driver posts a txslot for transmission), a single entry is placed on the tx pending slotFIFO 124.

The tx pending slot FIFO 124 is shown in further detail in FIG. 8A. Datais read from the head of the FIFO 124 and written to the tail. Txpending slot head and tail pointers 182 and 184 are used to access thehead and tail of the tx pending slot FIFO 124 respectively. A tx pendingslot controller 186 in the PCI bus interface 78 controls themanipulation of the head and tail pointers 182 and 184 and the transferof data to and from the tx pending slot FIFO 124.

The tx pending slot controller 186 takes advantage of the burst writecapability of the PCI bus 18 to provide a performance advantage. A PCIbus burst write transaction is shown in the timing diagram of FIG. 8B.Accordingly, when data is to be written to successive addresses via thePCI bus 18, this can be accomplished using a single PCI bus transactionhaving multiple data phases. Whereas the usual device mapped to a singleCSR address can be accessed only by separate and individual PCI writetransactions to that address, the device as herein described (the txpending slot FIFO 124) is accessible at any CSR address within asuccessive range of CSR addresses. The controller 186 recognizes a PCIburst write to a CSR address within this range, and then enables thewriting of data to the device during each successive data phase of aburst write to the successive CSR addresses within the range.

As previously shown in Table 1, the tx pending slot FIFO 124 isaccessible at any of CSR locations 0×0H−0×FH. Each tx pending slot FIFOentry is 2 longwords long; thus, 2 16 bit locations are used for eachentry. In order to post a series of tx slot descriptors to the txpending slot FIFO 124, the host 14 generates a PCI burst write tosuccessive CSR addresses within the range of the CSR locations 0×0Hthrough 0×FH. For each successive data phase of the burst write, thecontroller 186 writes the data to the FIFO 124 and increments the txpending slot tail pointer 184. When the tx pending slot FIFO 124 isfull, the PCI slave disconnects the host from the PCI bus. The burstwrite transaction is thereby advantageously used to load data to theFIFO.

The detailed operation of the CSR burst technique 188 employing the txpending slot FIFO controller is shown in the flow diagram of FIG. 9. Theentry_avail bit, when asserted, indicates that at least one entry 220,or two longwords, are available in the tx pending slot FIFO. The counternum_word_cnt keeps track of the number of entries (each of which are twolongwords long) present in the FIFO. Upon initialization (step 190),entry_avail is asserted to indicate that there is space available in theFIFO (step 192), and num_word_cnt=0; that is, the FIFO is empty (step194).

The tx pending slot controller 186 waits for a burst write from the PCIbus 18 to the tx pending slot CSR space 0H−0FH. When a burst writeoccurs (step 196), if the entry_avail signal is deasserted (step 198)indicating that no space is presently available in the tx pending slotFIFO 124, the PCI access is re-tried (step 199). As long as entry_availis asserted (step 198), then for each successive data phase of the burstthe data on the PCI bus 18 is written to the tx pending slot FIFO 124(step 200), the tx pending slot tail pointer 184 is incremented (step202), and the num_word_cnt counter 188 is incremented (step 204).

For example, if after initialization two entries 220(4 longwords) arewritten to the tx pending slot FIFO 124, the head pointer 182 points tolocation 0 while the tail pointer 184 points to location 4. When thehost 14 desires to write another tx pending slot, the host 14 performs aburst write to location 0h. The tx pending slot controller 186 sensesthe write to the tx pending slot CSR address space. For each data phasewithin the burst, the mapping logic writes the data to the tx pendingslot FIFO 124 and increments the tx pending slot tail pointer 184.

The tx pending slot controller 186 continues to process the burst writesin this manner until the num_word_cnt counter reaches 15, indicatingthat the FIFO 124 is full (step 206). The entry_avail bit is thendeasserted (step 208) and the tx pending slot controller 186 isdisconnected from the PCI bus (step 210).

Entries are read from the tx pending slot FIFO 124 by the tx DMAscheduler FSM 122. As will be further described in conjunction with thatmachine (FIG. 23e), when an entry is read from the tx pending slot FIFO124, the transmit pending slot head pointer 182 is incremented, thenum_word_cnt counter is decremented by two, and the entry_avail bit isasserted, thereby enabling further data writes to the tx pending slotFIFO 124.

FIG. 10 illustrates a tx pending slot FIFO entry 220. As shown, the txpending slot FIFO entry 220 comprises a number of different fields.Included is a RAW field 222, a single-bit field for indicating whetherthe transmit slot contains data for an AAL5 or idle packet (0) or for asingle 52-byte raw cell (1). An IDLE field 224 indicates whether thedata in the slot should be DMA'd and transmitted normally (0), orwhether the SAR controller should schedule an idle cell for transmissionfor every cell contained in the slot (1). This bit is used for timingMPEG streams. When it is set, no data from the tx slot will be DMA'd ortransmitted on the network 16. A single-bit MGMT field 226 indicates ifthe data in the slot constitutes an F4 or F5 OAM cell. When this bit isset, it indicates to the SAR controller 62 that the data in the slotshould be transmitted whether or not the VC of the data has Flowmastercredits available (even if the VC is under Flowmaster flow control). AVC field 228, shown as a 12-bit field, is used to indicate the VC withwhich the tx slot data is associated. A CRC10_EN field 230 is a 1-bitfield which is only of significance when the RAW field bit is set. Thebit in the CRC10_EN is used to select whether or not a 10-bit CRC shouldbe calculated and appended to the raw cell being transmitted. CRC10_ENshould be set to 0 for AAL5 slots. Generally, it is set to 1 for both F4and F5 OAM cells. An EOP field 232 is used for two purposes: to indicatethat a transmit slot contains the last byte of data of an AAL5 or idlepacket (raw=0), or to indicate that a status report and interrupt shouldbe generated on completion of the DMA of a raw cell slot (raw=1).

Also included in the tx pending slot FIFO entry is a slot size(SLOT_SIZE) field 234, shown as a 14-bit field, for indicating thenumber of bytes contained in the transmit slot. If the slot is a rawcell slot (raw=1), then this field should always be set to 52 by thehost system. For AAL5 or idle slots (raw=0), this field must be in therange 1-16383 (the value 0 is not allowed). A reserved field 236 is alsoprovided. Lastly, the tx pending slot FIFO entry includes a BASE_ADDRESSfield 238, implemented as 32-bits wide, for indicating the physical baseaddress of a transmit slot in host memory. It may contain any value foridle slots, since no data is DMA'd from idle slots.

With continuing reference to FIG. 6, the tx DMA scheduler FSM takesentries off of the tx pending slot FIFO and places data from the entriesonto the tx active slot lists 162, as will be further described withreference to that machine. FIG. 12 illustrates the tx active slot lists162. The tx active slot lists 162 are “per VC” lists having tx activeslot list entries 239. Each tx active slot list entry includes a tx slotdescriptor 240, which is associated with a single tx slot in hostmemory. It can be understood from the figures that the tx slotdescriptors are therefore comprised of information from all but the VCfield 228 in the tx pending slot FIFO entry 220. The VC field is used toqueue a tx slot descriptor contained in fields 222-226 and 230-238 inthe pending slot FIFO entry to the appropriate tx active slot list. Inthe described embodiment, there are 1K active slot lists and each isorganized as a linked list. Therefore, each tx active slot list entry239 further includes a link field 241, which contains a pointer to thenext tx slot descriptor on the list. A head pointer 240 and tail pointer240 for pointing to the head and tail, respectively, of each of the txactive slot lists are 12-bits wide and are obtained from the tx VC statetable 148 (from FIG. 7).

Storage for each tx slot descriptor in the tx active slot lists is takenfrom the tx free slot list 161, also located in the local memory 76 asshown previously with reference to FIG. 6. The size of the tx free slotlist, according to the described embodiment, is 1K entries. FIG. 13illustrates the tx free slot list 161. With reference to FIG. 13, the txfree slot list 161 includes tx free slot entries 244, which each includethe link field 241 and an empty portion 248 (which is written with a txslot descriptor from the pending slot FIFO). The entries are taken fromthe head of the free slot list, pointed to by a base_ptr 250 and placedon the tail of the list, being pointed to by end_ptr 252. The base_ptr250 and end_ptr 252 (from FIG. 13) are stored in one of the CSRs on theSAR controller itself.

FIG. 13 illustrates the format of the tx active slot list entry 239 fromFIG. 11. With the exception of the link field 241, the fields are thesame as the equivalently named fields in the tx pending slot FIFOentries and thus retain the reference numbers used in FIG. 10.

Once the data in a posted tx slot has been transmitted, the tx free slotFIFO entry associated with the tx slot is returned to the free slot listby the tx DMA scheduler FSM. The driver keeps a count of the totalnumber of slots (across all VCs) queued but not yet transmitted, andensures that this number never exceeds the total number of supported txslot descriptors. This number is determined by the size of the free slotlist, which is exactly 1K.

Both the tx free slot list and the tx active slot lists are initializedby the driver at initialization time. Initialization of the tx free slotlist consists of writing every link field in the tx free slot listentries (1K−1 links) to create a linked list, and writing the base andend pointers of the tx free slot list in the CSRs. Initialization of thetx active slot lists consists of writing the head and tail pointers ofall of the tx active slot lists with the value 0, since all tx activeslot lists are initially empty.

In the embodiment described herein, the tx control memory 184 includesthe tx pending slot FIFO 124, the tx free slot list 161 and the txactive slot lists 162; however, alternative implementations of the txcontrol memory may be utilized. For example, in a network nodesupporting only one VC, the tx control memory 184 could be implementedas a single data structure, such as a list. A linked list is preferable,as it allows tx slots which are noncontiguous with respect to oneanother to be chained for a given PDU that spans multiple tx slots.

As previously indicated, the network node of the described embodimentsupports up to 1K active VCs. When a VC is opened, it is set-up as anAAL5 VC, an AAL3/4 VC, or some other type of flow. The SAR controller 62recognizes three types of flow: AAL5, Raw and MPEG. Two bits in the txVC state table 148 for a given VC identify the type of flow to which theVC has been assigned. In the following description, any reference toAAL5 streams includes MPEG streams (since MPEG streams are assumed to becarried over AAL5). An MPEG stream is different from an AAL5 stream onlyin that a single MPEG packet (“super-packet”) may be segmented intoseveral AAL5 packets. When packets are transmitted on a VC which is anAAL5 VC, the AAL5 CRC will be computed and appended to the packets.OAM-F5 cells are identified through the PT field of the cell, ratherthan by the VC field, and may be carried on the same VC as an AAL5 flow.Whenever the host system wishes to transmit an F4 or F5 OAM cell, itneeds to set the bits of the raw and crc10_en fields in the tx slotdescriptor for the cell. The setting of these bits indicates to the SARcontroller that the tx slot contains a single raw cell for which theCRC-10 must be computed and appended. It also indicates, in the case ofF5 cells carried over an AAL5, that the CRC-32 of the cell's VC in thetx VC state table should not be updated.

It should be noted that, aside from the fact that they do not affect theCRC-32 calculation, OAM-F5 cells are treated no differently than datacells of the VC on which they are being sent. In terms of DMA andtransmit scheduling and for purposes of ABR rate-based flow controlcalculations they are considered part of the normal data flow of the VC.OAM-F4 cells are identified by their VC (VC=3 or 4). The SAR controllerwill generate the CRC-10 field for all transmitted cells for which thebit of the crc10_en field is set. It will then overwrite the appropriatebits in the transmitted cell with the calculated CRC-10 value. Thisfunction may be used to aid in the transmission of AALs other than AAL5which use the CRC-10, such as AAL3/4.

FIG. 14 depicts the format of a tx VC state table entry 254 in the tx VCstate table 148. As shown, the entry comprises 8 words. Word 0 providesa two-bit channel type (chtyp) field 256 for indicating the channeltype. The two bit field is decodes as follows: 00 corresponds to a rawcell data, 01 is reserved, 10 corresponds to AAL5 and 11 corresponds toMPEG cell data.

A streaming mode enable (tx_AAL5_SM) field 258 is a one-bit field forenabling streaming mode for AAL5 cells. This field is used for reportsand interrupts, as will be seen later. An FLOWmaster enable (FM) field260 is set to enable FLOWmaster control support. Word 0 furthercomprises an ABR parameter base set selection (ABS) field 262 and a ratecontrol (R) field 264 to indicate the particular rate control selected.This two-bit field is decoded as follows: 00 corresponds to CBR, 01 isset for ABR, 10 is set for UBR and 11 is reserved. A one-bit cell losspriority (CLP) field 266 indicates the cell loss priority transferred tothe ATM header of the transmitted AAL5 cells. Lastly, word 0 includes aprescale counter value (prescale_val) field 268 for providing theprescale counter initial value for CBR and UBR rate control. Theremaining bits (7:4) are contained in reserved field 270. Referencenumber is used to indicated all of the five reserved fields shown in thefigure.

Now referring to word 1, the entry further comprises an MPEG_count field272, which serves as a counter for counting the number of cells in anMPEG packet. A Prescale_count field 274 is a down counter used forslowing down CBR/ABR/UBR rates. A credit field 276 provides a FLOWmastertransmit credit counter. The MSB of word 1 is a second reserved field270.

Together, Words 2 and 3 correspond to a 32-bit CRC 278 for transmittedAAL5 packets. Particularly, word2 contains the low word and word 3 thehigh word. Word4 includes an active field 280, a flag to indicate thatdata exists in the active slot list for a VC, and a schedule flag 282 toindicate that a VC is scheduled in the ABR/UBR schedule table. Anout-of-rate backward RM (OR_BRM) flag 284 is used to indicate that anout-of-rate backward RM cell should be transmitted. A turn field 286 isa flag for indicating that a backward RM turn-around cell is pending.Also provided is a tx active slot list head pointer 288 and, in word5, atx active slot list tail pointer 290. Word5 also includes a thirdreserved field 270.

Words 6 and 7 include a fourth reserved field 270 and a fifth reservedfield 270 respectively. Word6 also includes a transmit slot pointer(tx_slot_ptr) 292 corresponding to the byte offset into the current slotfrom which transmit data is being DMA'ed on a VC and an idle field 294.Lastly, word7 provides for ABR or UBR schedule pointers in a VC_linkfield 296.

As already stated above, the SAR controller provides support fortransmission of data encoded according to the MPEG standard through theuse of MPEG Super-Packets. FIG. 15 illustrates the format of an 8 cellAAL5 packet 296 carrying two MPEG PDUs 297 and an AAL5 trailer 298. Eachof the MPEG PDUs 297 is exactly 188 bytes in length. This means that 2MPEG PDUs (376 bytes) may be packed together into a single 8-cell AAL5packet with no AAL5 padding, as shown. An MPEG super-packet is a packetprovided by the driver which may contain any even number of MPEG PDUs ona VC which has been specified as an MPEG VC (in the tx VC state table).The SAR controller automatically segments the packet into 1 or more AAL5packets, placing 2 MPEG PDUs in each AAL5 packet.

The driver does not provide any AAL5 information in MPEG super-packets(as opposed to AAL5 packets, which must include the AAL5 pad, controland length fields and a 4-byte CRC placeholder). For example, if thedriver wishes to transmit 10 MPEG PDUs in a single MPEG super-packet, itposts an MPEG super-packet exactly 1880 bytes in length (188×10). TheSAR controller then segments the super-packet into 5 AAL5 packets andappend the appropriate AAL5 length (376), control (0) and CRC fields toeach AAL5 packet. As with other AAL5 packets, MPEG super-packets may beposted across any number of slots.

SAR Controller Segmentation Engine

The segmentation engine 88 of the SAR controller 62 functions to segmentdata provided by the driver 24 into fixed length cells to be transmittedto the PHY 80. The data to be segmented into cells and transmitted on agiven VC resides in host memory 22; therefore, the elements shown inFIG. 6 interoperate in part to schedule DMA requests to host memory 22to retrieve data for each VC and to transmit that data from the tx dataFIFO 132 according to the traffic class and rate requirements for thatVC.

In brief overview, the tx DMA scheduler 122 reads the tx pending slotFIFO 124 and moves transmit slot descriptors 240 (FIGS. 11-13) from thefree slot list 161 to the active slot lists 162. The schedule table 174,which includes the CBR schedule table 176 and ABR schedule table 178,holds entries corresponding to CBR and ABR/UBR VCs to be transmitted.The tx rate scheduler FSM 120 (hereinafter tx rate scheduler 120) loadsthese entries into the schedule table 174 at locations determined inaccordance with the rate requirements for the VCs. The tx rate scheduler120 scans the cbr and ABR schedule tables 176 and 178, processing eachof the entries in the tables sequentially. For each entry read, the txDMA scheduler FSM 122 (hereinafter tx DMA scheduler 122) places a CBR orABR tx DMA request entry in the tx DMA request FIFO 125, updates the txVC state table 254, and moves tx slot descriptors 158 from the tx activeslot lists 162 to the tx free slot list 161 as necessary.

The tx DMA FSM 126 processes the entries in the tx DMA request FIFO 125,generating a single burst read request to the PCI bus 18 for entriesrequiring the transfer of data from host memory 22 into the tx datasynch fifo 128. The tx data synch fifo 128 provides buffering betweenthe PCI bus 18 and SAR controller 62 clock domains. The tx cell FSM 130in turn controls the transfer of data between the tx data synch fifo 128and the tx data fifo 132.

The tx data fifo 132 serves as the transmit buffer memory, and as hereinshown holds up to 16 CBR and/or ABR/UBR cells for transmission to thePHY interface 80. The configuration of the tx data fifo 132 depends uponwhether GFC is enabled. The configuration of the tx data fifo 132affects the operation of the various FSMs, and so is now described indetail.

Dual Mode Tx data fifo 132

Recall that, when GFC is enabled and SET_A is deasserted, controlledABR/UBR traffic is halted while uncontrolled CBR traffic continues toflow. If both controlled and uncontrolled traffic are buffered in asingle tx data FIFO 132 when GFC is enabled, then if a controlledABR/UBR cell is at the head of the FIFO and GFC set_A is deasserted, anyuncontrolled CBR traffic behind the pending ABR/UBR cell is unacceptablyblocked from transmission.

A dual-mode tx data FIFO 132 is therefore provided. Referring to FIG.16a, when GFC is disabled, the tx data FIFO 132 is configured as asingle FIFO for holding CBR, ABR, and UBR traffic. When GFC is enabled,however, the tx data FIFO 132 is segmented into a cbr tx data FIFO 300for holding uncontrolled CBR traffic and an abr tx data FIFO 302 forholding controlled ABR and UBR traffic, as shown in FIG. 16b. When GFCis enabled and set_A is deasserted, only the abr tx data FIFO 302traffic flow is halted. The separate cbr and abr tx data FIFOs 300 and302 thereby prevent blocking of uncontrolled traffic in the event thatcontrolled traffic is halted.

More particularly, when GFC is disabled (FIG. 16a), as indicated by thedeassertion of a segmented_fifo signal by the tx data FIFO 132, the txdata FIFO 132 is configured as a single FIFO for holding CBR, ABR, andUBR VCs. A single set of head and tail pointers controls access to thetx data FIFO 132, shown here as tdf_head_ptr 304 and tdf_tail_ptr 306.When GFC is enabled (FIG. 16b), the signal segmented_fifo is asserted bythe PHY and the FIFO is bifurcated into a cbr tx data FIFO 300 forholding uncontrolled cells and an abr tx data FIFO 302 for holdingcontrolled cells. Two separate sets of pointers are then used. Atdf_abr_head_ptr 308 and tdf_abr_tail_ptr 310 control access to and fromthe abr tx data FIFO 302, while a tdf_cbr_head_ptr 312 andtdf_cbr_tail_ptr 314 control access to and from the cbr tx data FIFO300.

Consider now the provision of dual FIFOs for controlled and uncontrolledtraffic in combination with the provision of only a single DMA requestFIFO 125 (FIG. 6). When GFC flow control is enabled and SET_A isdeasserted, the flow of cells from the abr tx data FIFO 302 is halted,while uncontrolled CBR cells should continue to flow from the cbr txdata FIFO 300. Consider that the abr tx data FIFO 302 becomes full, andthen a DMA request for an ABR cell is scheduled into the DMA requestFIFO 125. Once the ABR entry rises to the head of the DMA request FIFO125, back pressure from the abr tx data FIFO 302 prevents the processingof the request. Therefore, any uncontrolled CBR entries behind the ABRentry in the tx DMA request FIFO 125 will not be processed either.

This problem can be prevented through the provision of dual DMA requestFIFOs—one for controlled and one for uncontrolled traffic. However, theproblem is herein solved while allowing the efficient use of a singleDMA request FIFO 125. Accordingly, when GFC flow control is enabled, thetx DMA scheduler 122 will not schedule DMA requests from the ABRschedule table 178 unless the abr tx data FIFO 132 can accommodate atleast one cell. A fifo_remain controller 316 keeps track of the numberof entries outstanding in the abr tx data FIFO 302. Thus, whereas cbrDMA scheduling may be prevented by back pressure from the cbr tx dataFIFO 300, abr DMA scheduling is counter controlled.

As seen in FIG. 6, The fifo_remain controller 316 is coupled between thetx phy FSM 134 and the tx rate scheduler 120. The fifo_remain controller316 is shown in more detail in FIG. 17 to include a counter 317 and acomparator 318. It accepts as input a DMA_request_on_abr signal from thetx rate scheduler 120 and a read_entry_dec[1:0] vector from the tx phyFSM 134, and produces as output a fifo_remain≧16LW signal which is fedto the tx rate scheduler 120. A flow diagram representing the operationof the counter 317 is shown in FIG. 18.

As herein embodied, the tx data FIFO 132 is a 1K byte FIFO which may besegmented into a 512 byte cbr tx data FIFO 300 and a 512 byte abr txdata FIFO 302. At step 319 the counter 317 is initialized to 128longwords, which is the number of longwords available in the empty abrtx data FIFO 302. Upon assertion of the DMA_request_on_abr bit by the txDMA scheduler 122 (step 320), which indicates that a DMA request for anABR/UBR cell has just been queued to the DMA request FIFO 125, thecounter 317 is decremented by the number of bytes associated with thetype of cell requested. The cell requested is one of three types: raw,AAL5, or RM. As will be further described in conjunction with the txdata FIFO 132, raw cells consume 14 longwords in the FIFO, AAL5 cellsconsume 13 longwords, and RM cells consume 3 longwords. Thus, for a rawcell, the counter 317 is decremented by 14 (steps 322 and 324), and forAAL5 cells, by 13 (steps 326 and 328). If the cell requested is neitherraw or AAL5, then the counter 317 is decremented by the size of an RMcell, i.e. by 3 (step 332).

When a cell is transferred out of the abr tx data FIFO 302, theread_entry_dec[1:0] vector takes on a non-zero value that encodes thetype of cell transmitted. In this case the counter 317 is incremented bythe number of bytes in the cell transmitted. Thus, when theread_entry_dec[1:0] vector is decoded to indicate transmission of a rawcell, the counter 317 is incremented by 14 (steps 336 and 338). Decodeof an AAL5 cells increments the counter 317 by 13 (steps 340 and 342).Decode of an RM cell increments the counter 317 by 3 (steps 344 and346).

The output of the counter 317 is input to the comparator 318, where itis compared to a value of 16 longwords. As long as the counter 317output remains greater than or equal to 16 longwords, thefifo_remain≧16LW signal remains asserted and does not prevent DMAscheduling of VCs from the ABR schedule table 178. If the counter 317output should ever fall below 16 longwords, the fifo_remain≧16LW signalwill be deasserted, preventing further abr DMA scheduling until a cellis transferred out of the abr tx data FIFO 302.

Note that the above described controller 316 is useful in general fortransferring various sorts of data units, some of which are subject to aflow control mechanism, between a host memory and a peripheralinterface. Where there is generally provided two transmit buffermemories, one for holding flow controlled data units (i.e. the abr txdata FIFO 302) and one for holding uncontrolled data units (i.e. the cbrtx data FIFO 300), and it is desirable to provide only a single requestbuffer (i.e. the tx DMA request FIFO 125), a controller such as thefifo_remain controller 316 can prevent data transfer circuitry (such asthe combination of the tx rate scheduler FSM 120, tx DMA scheduler FSM122, and tx DMA FSM 126) from transferring further data from the hostmemory to the transmit buffer memory storing the flow controlled dataunits when it is determined that there is not enough room in thetransmit buffer memory storing the flow controlled data units toaccommodate another data unit. Meanwhile, the controller 316 allows thedata transfer circuitry to transfer further data from the host memory tothe transmit buffer memory storing the uncontrolled data units.

Note also that, though the previously described embodiment employs acounter for keeping track of the space remaining the the abr tx dataFIFO 302, other embodiments can be used to achieve the same result. Forexample, a counter could be used to keep track of the number of entriesused in the FIFO, rather than the number of entries remaining.

Each element shown in FIG. 6 is now described in detail.

Tx DMA request FIFO 125

As the tx rate scheduler 120 scans the schedule table 174, DMA requestsare generated by the tx DMA scheduler 122 and placed as entries in thetx DMA request FIFO 125. These entries are then read by the tx DMA FSM126, which processes the entries and generates DMA requests for datafrom host memory 22. Referring now to FIGS. 19a-19 c, The tx DMAscheduler 122 may generate any of 3 types of entries: a data DMA requestentry 350, an idle slot report request entry 352, or an RM cell requestentry 354. Fields in the first word of the entry identify the type ofentry, as shown in Table 2.

TABLE 2 Tx DMA request FIFO 125 Entry Type Decoding RM DMA_SIZE<5:0>ENTRY TYPE 0 >0 Data DMA Request 0  0 Idle Slot Report Request 1 N.A. RMCell Request

The three types of tx DMA request FIFO 125 entries are defined asfollows:

Data DMA Requests

This type of entry represents a single request by the tx DMA scheduler122 to read data from host memory 22. Each data DMA request is processedby the tx DMA FSM 126, and results in a single burst read request to thePCI bus 18.

FIG. 19a illustrates a data DMA request entry 350. This entry isidentified by (RM=0) and (DMA_Size>0).

Data DMA Request Entry Fields:

VC (356)

This 12-bit field identifies the VC to which the data to be DMA'd fromhost memory 22 belongs. The VC is that obtained by the tx rate scheduler120 when reading either a valid CBR schedule table entry or a worklistentry.

Sched_Time (358)

This 8-bit field is a timestamp representing the time at which the DMARequest was placed in the tx DMA request FIFO 125. It does not affectthe functioning of the tx DMA FSM 126, but is placed by the tx Cell FSM130 in the tx data FIFO 132 along with the data to be transmitted. Thefield is then used by the tx phy FSM 134 to resynchronize celltransmission, so that the pattern of cells emerging at the PHY interface80 more closely resembles the pattern seen in the schedule table 174 bythe tx rate scheduler 120, as will be further described in conjunctionwith the tx rate scheduler 120 and the tx phy FSM 134.

RM (360)

This 1-bit field is cleared (0) for data DMA request entries. Itdifferentiates the entries from RM cell request entries.

CLP (362)

This 1-bit field indicates the value of the CLP bit which should beinserted in the AAL5 cell transmitted. It has no meaning for raw cells.

CRC_Ena (364)

This 1-bit field when set indicates that a CRC must be computed acrossthe data DMA'd as a result of the request. If the request is for a rawcell (as indicated by the fact that the DMA_Size field of the request isequal to 52 bytes), then this bit indicates that a CRC-10 will becomputed and inserted in the raw cell transmitted as a result of therequest. If the request is for part of an AAL5 packet (DMA_Size field ofthe request is not equal to 52 bytes), then this bit indicates that aCRC-32 should be computed across the data DMA'd and transmitted as aresult of the request.

EOP (366)

This 1-bit field indicates if the DMA burst to be executed is either:

A burst of a number of bytes containing the last byte of data in an AAL5packet; or

A 52-byte burst of a raw cell whose EOP bit is set.

 The bit is used by the tx cell FSM 130 to determine AAL5 packetboundaries, in order to write computed AAL5 CRCs to the tx data FIFO 132at the appropriate time. This bit does not affect the functioning of thetx DMA FSM 126.

DMA_Size (368)

This 6-bit field differentiates data DMA request entries from idle slotreport request entries and indicates the number of bytes to DMA'd fromhost memory 22. It will be 0 for idle slot report request entries andnon-zero for data DMA request entries. For raw cell slots, this fieldwill always indicate 52 bytes. For AAL5 slots, this field will usuallyindicate 48 bytes, except sometimes at slot boundaries, and it willnever indicate more than 48 bytes.

Int (370)

This 1-bit field when set indicates that a tx status report should becompleted and a tx interrupt generated upon completion of the DMA'ing ofdata.

EOC (372)

This 1-bit field indicates whether or not the request is for the end ofan AAL5 or raw cell. EOC is set to 1 for every raw cell request(DMA_Size=52) and for every request which results in the DMA of the 48thbyte of data of an AAL5 cell.

Add MPEG_Trailer (374)

This 1-bit field when set indicates that an AAL5 trailer should beappended to the end of the data DMA'd when the data is placed into thetx data FIFO 132 by the tx cell FSM 130. This bit is set at 376-Byteboundaries of MPEG super-packets. The AAL5 trailer appended will consistof 0 bytes of paddings, a length field=376 bytes, control field=0, and a4-byte CRC.

CBR (376)

This 1-bit field indicates whether the request is associated with a CBRor ABR/UBR VC, and is used when GFC is enabled in order to direct thedata associated with the request to the appropriate cbr or abr tx dataFIFO 300 or 302.

DMA Address (378)

This 32-bit field indicates the physical address in host memory 22 fromwhich data should be DMA'd.

Idle Slot Report Requests

Idle slot report requests do not result in any data being DMA'd fromhost memory 22. Idle slots are used in part by the host 14 for finetuning of CBR traffic rates. The purpose of an idle slot report requestis to indicate to the tx DMA FSM 126 that it should report to the hostdriver 24 the consumption of an idle slot. Transmit reporting is alsodiscussed in detail later.

The tx DMA scheduler 122 issues idle slot report requests only for thelast cell of an idle slot, and only when the EOP bit for the idle slotis set (FIG. 10), indicating that consumption of the slot should bereported. If an idle slot does not have its EOP bit set, the tx DMAscheduler 122 will consume the slot without actually issuing any DMArequests for the slot. FIG. 19b illustrates an idle slot report requestentry 352. This entry is identified by (RM=0) and (DMA_Size=0).

Idle Slot Report Request Entry Fields:

VC (380)

This 12-bit VC identifies the VC for which an idle slot was consumed.

RM (382)

This 1-bit field is cleared (0) for idle slot report request entries. Itdifferentiates the entries from RM cell request entries.

DMA_Size (384)

This 6-bit field differentiates idle slot report request entries fromdata DMA request entries. It indicates the number of bytes to DMA'd fromhost memory 22, and will thus always be 0 for idle slot report requestentries and non-zero for data DMA request entries.

RM Cell Requests

This type of entry represents a single request by the tx DMA scheduler122 to transmit an RM cell on the link. This request does not result inthe DMA of any data from host memory 22. It is simply an indication tothe tx DMA FSM 126 that it must request that the appropriate RM cell becreated and placed in the tx data FIFO 132 for transmission. FIG. 19cillustrates an RM cell request entry 354.

RM Cell Request Entry Fields:

VC (386)

12-bit field identifies the VC on which an RM cell should betransmitted.

Sched Time (388)

This 8-bit field is a timestamp representing the time at which the RMCell Request was placed in the FIFO. It does not affect the functioningof the tx DMA FSM 126 or tx cell FSM 130, but is placed in the tx dataFIFO 132 along with the data to be transmitted. The field is then usedby the tx phy FSM 134 to resynchronize cell transmission, so that the RMcell is transmitted at the appropriate time.

RM (390)

This 1-bit field is set (1) for RM cell request entries. Itdifferentiates the entries from the 2 other types of entries in theFIFO.

CLP (392)

This 1-bit field indicates the value of the CLP bit which should beinserted in the transmitted RM cell.

Forward (394)

This 1-bit field indicates whether the RM cell to be generated is aforward RM cell (1) or a backward RM cell (0).

Schedule Table

The segmentation engine 88 uses a schedule table and worklist-basedapproach to DMA scheduling, wherein flows are represented by their VCsin the schedule table 174, shown in more detail in FIG. 20a. Theschedule table 174 is a data structure located in local memory 76. Itincludes a CBR schedule table 176 and an ABR schedule table 178. Asherein embodied, the CBR schedule table 176 contains from 2 to 4096entries 400 used to schedule CBR flows, and the ABR schedule table 178contains 4K entries 402 used to schedule ABR and UBR flows.

Each location or row 404 in the schedule table 174 represents a point intime that is 1 cell time (at whatever rate the physical interface 80 isrunning) from the adjoining rows. For example, at STS-3c/STM-1 linerates, the first row 404 in the schedule table 174 is associated with atime t=0, the next row 404 with a time t≈2.83 μs, and the next row 404with a time t≈5.66 μs. Cell data is transferred from the tx data FIFO132 to the PHY interface 80 at the line rate; thus, each location 404represents a point in time at which data can be transferred from the txdata FIFO 132 to the PHY interface 80. The schedule table 174 operatesas a circular structure, such that, for example, the entry at row (4095)adjoins the entry at row (4094) and the entry at row 0 in the ABRschedule table 178.

There are 2 separate columns in the CBR schedule table 176: cbr_vc1(408) and cbr_vc2 (410). Each is a word wide and may include a singleentry 400. Each entry 400 contains a 12-bit VC field 412, along with avalid bit 414 and an EOT bit 416. These fields indicate the CBR flow tobe scheduled for transmission at the time at which the entry appears.When the valid bit 414 is asserted, the VC 412 in the entry 404 isvalid. Otherwise, there is no CBR VC to be scheduled at the timerepresented by the entry 404. The EOT bit 416 is used to indicate thelast entry 404 in the CBR schedule table 176.

Only one cbr_vc column is used at one time. The column in use isselected by the driver 24 through manipulation of a cbr-st-sel controlbit in a CSR (not shown). The provision of two cbr_vc columns in the CBRschedule table 176 supports modification of CBR rates in real-time bythe driver 24. At initialization time, the driver 24 will select thecbr_vc1 column 408 by setting the cbr_st_sel bit to 0, and initializingall entries in the column. When the driver 24 wishes to modify the CBRschedule, it will write the entries in the cbr_vc2 column 410 with thenew schedule, then toggle the cbr_st_sel bit to 1. The tx rate scheduler120 will then start using the cbr_vc2 column to schedule thetransmission of CBR flows. If the driver 24 wishes to modify theschedule once again, it will modify the cbr_vc1 column, then toggle thecbr_st_sel bit back to 0.

An ABR schedule table entry 402 includes an abr_head field 418 andabr_tail field 420, each of which hold 12-bit pointers into a VC list180, located in local memory 76. In addition, the abr_head fieldcontains a valid bit 422. The VC list 180 is an array of 1K entries 424,each of which is a 12 bit pointer to another entry 424 in the list. Eachentry 424 represents a VC, depending on its position in the array. Forexample, using the term VCL[i] to represent the ith entry in the VClist, VCL[5] represents VC 5, whereas VCL[256] represents VC 256. Asherein implemented, the entries in the VC list 180 are the VC_linkfields 295 in the tx VC state table 254 for each VC.

The abr_head field 418 of an ABR schedule table entry 402 is a pointerthat points to the beginning of a linked list of VCs kept in the VC list180. The abr_tail field 420 of an ABR schedule table entry 402 is apointer that points to the end of a linked list of VCs kept in the VClist 180.

Thus, the abr_head and abr_tail pointers 418 and 420 of the ABR scheduletable entries 402 along with the VC list 180 are used to assign a linkedlist of ABR and UBR VCs to each ABR schedule table entry 402. The linkedlist of ABR and UBR VCs located at a given schedule table entry 402contains the complete set of ABR and UBR VCs which are scheduled totransmit a cell at the time slot represented by the location 404 of theentry 402 in the ABR schedule table 174.

The valid bit 422 indicates whether or not the abr_head and abr_tailpointers 418 and 420 in a given entry 402 are valid. When the valid bit422 is asserted, the pointers in the entry are valid. Otherwise thereare no ABR or UBR VCs to be scheduled at the time represented by theentry 402, and the pointers are ignored.

FIG. 20a shows 2 separate lists implemented using the abr_head andabr_tail fields 418 and 420 of the ABR schedule table 178 and the VClist 180. The list indicated by entry 402 at location 56 contains 4entries 424: 3, 4, 1201, and 1. The list indicated by entry 402 atlocation 57 contains 2 entries 424: 5 and 1022.

As the ABR schedule table 178 is scanned by the tx rate scheduler FSM120, the ABR/UBR list at the current schedule table entry 404 isappended to the tail of a linked list called the ABR/UBR work list 428(hereinafter “work list 428”), shown in FIG. 20b. The work list isimplemented with two worklist pointers 123 stored within thesegmentation engine 88, the worklist_head and worklist_tail pointers 430and 432. These two structures are pointers into the VC list 180. Aschedule table ABR/UBR list is appended to the work list by copying thevalue of abr_head 418 into the location in the VC list 180 pointed to byworklist_tail 432, and copying the value of abr_tail 420 intoworklist_tail 432.

The work list shown in FIG. 20b could have been produced by scanningschedule table entries 56 and 57, for example, where abr_head atlocation 56 pointed to VC list entry 3 and abr_tail pointed to VC listentry 1, abr_head at location 57 pointed to VC list entry 5, andabr_tail at location 57 pointed to VC list entry 1022.

The ABR/UBR work list 428 is used to keep track of ABR and UBR cells tobe DMA'd and transmitted. Whereas CBR VCs are read directly from the CBRschedule table 176 and then scheduled for DMA, ABR. and UBR VCs arefirst copied onto the tail of the work list 428 from the ABR scheduletable 178, then scheduled for DMA when they appear at the head of thework list 428. As ABR VCs are scheduled for DMA, they are popped off ofthe work list 428, then rescheduled into the schedule table 178according to the ABR parameters in effect at rescheduling time. As UBRVCs are scheduled for DMA, they are popped off of the work list 428 andrescheduled into the schedule table 178 at the location specified by thepeak cell rates of the VCs. When an ABR or UBR VC is rescheduled into agiven entry in the ABR schedule table 178, it is added to the head ofthe ABR/UBR list located at the given schedule table entry, as will befurther described in conjunction with the tx rate scheduler FSM 120. Theschedule table 174 according to the preferred embodiment supports CBRrates, ABR allowed cell rates or UBR peak rates in the range ofapproximately 36.6 kb/s to 149.76 mb/s. However, it may be desirable toachieve CBR rates or UBR peak rates down to approximately 8 Kb/s, and itis essential for compliance with the ATM Forum Traffic ManagementSpecification to support ABR rates down to 4.2 kb/s (10 cells/s). Inorder to achieve these low rates without expanding the schedule table toan unreasonable size, 2 per-VC variables, Prescale_val (268) andPrescale_count (274), stored in the tx VC state table 254 (FIG. 14), areused.

Prescale_val specifies a scaling-down of the basic schedule-tableimplemented rate according to the following equation:

Rate=Schedule_table_rate/(Prescale_val+1)

For example, if prescale_val for a VC is programmed with the value 0,then the rate specified on the VC will be equal to that implemented bythe schedule table 174. If prescale_val is programmed with the value 1,the rate on the VC will be half that implemented by the schedule table174. Prescale_count is used by the tx rate scheduler 120 to perform thescaling-down operation, as will be further described.

For CBR flows, prescale_val is programmed by the driver 24 and is nevermodified by the SAR controller 62. A given CBR rate maps into a givenpattern of entries in the CBR schedule table 176 as follows: for everyentry for a given VC in the CBR schedule table 176, the entry willreceive (1/(st_size* (prescale_val+1)))th of the link bandwidth, wherest_size is the size of the CBR schedule table 176 in units of entries.Thus, if a VC appears only once in the CBR schedule table 176,prescale_val for the VC is set to 0, and the CBR schedule table 176contains 2119 entries, the VC will receive (1/2119)*149.76 Mb/s=70.67Kb/s of bandwidth at STS-3c/STM-1 line rates. If, for example, thedriver 24 wishes to allocate one half of the link bandwidth to CBR VC J,it fills half of the cbr_vc entries in the cbr_vc column being used withthe value J, and programs prescale_val for the VC with 0.

For ABR and UBR flows, prescale_val is not used. The tx rate schedulermodifes prescale_count as necessary, according to the ABR protocol forABR flows, or according to the fixed peak rate specified by the driver24 for UBR flows. For all three types of flows, prescale_count isinitialized to 0 by the driver 24.

Tx rate scheduler FSM and tx DMA scheduler FSM

The tx rate scheduler FSM 120 performs the following functions:

scans the off-chip schedule table 174, reading cbr entries 400 from theCBR schedule table 176 and abr entries 402 from the ABR schedule table178;

for each valid entry found in the schedule table 174, calls the tx DMAscheduler FSM to post a data DMA request or idle slot report request tothe DMA request FIFO 125;

calculates, in the RM cell request generator 435, the timing for thegeneration of RM cells according to ABR rates in effect for a given ABRVC, and posts requests to the tx DMA scheduler 122 to post an RM cellrequest to the DMA request FIFO 125;

reschedules ABR and UBR flows which have had DMA requests posted to thetx DMA request FIFO 125 by the tx DMA scheduler 122;

schedules new, presently unscheduled ABR/UBR VCs into the ABR scheduletable 178.

The tx DMA scheduler 122 performs the following functions:

It reads the tx pending slot FIFO 200 and moves tx slot descriptors 158from the tx free slot list 161 to the appropriate tx active slot list162 as necessary;

In response to requests from the tx rate scheduler FSM 120, it readsparts of VC state from the tx VC state table 254, reads tx slotdescriptors 240 from the active slot list 162, and queues ABR, UBR, andCBR data DMA requests, idle slot report requests, and RM cell requeststo the tx DMA FIFO 125.

It moves tx slot descriptors 240 from tx active slot lists 162 to the txfree slot list 161 as tx slots are consumed.

According to the preferred embodiment, the rate at which the tx ratescheduler 120 (also referred to as the tx rate scheduler 120 ) scans theschedule table is at least 1.2 times as fast as a cell time atSTS-3c/STM-1 line rates (≈2.83 μs). This allows the tx rate scheduler120 to effectively “look into the future” a number of cell times andpost requests to the tx DMA scheduler 122 to fill the tx DMA requestFIFO 125 with requests for PCI transfers if PCI latency prohibits the txDMA FSM 126 from making progress on the requests. This ensures that thePCI bus 18 can be used efficiently by the tx DMA FSM 126 when busbandwidth becomes available.

As seen in FIG. 20a, five different pointers facilitate the scanning ofthe schedule table by the tx rate scheduler 120: CBR_current_time (436),ABR_current time (438), CBR_sch (440), CBR_schedule_time (not shown),and ABR_schedule_time (444). The CBR_current_time and ABR_current_timepointers keep track of the time at which cells associated with entriesin the CBR and ABR schedule tables are to be transferred from the txdata FIFO, while the ABR_schedule_time and CBR_sch pointers are used bythe tx rate scheduler FSM 120 to scan the schedule tables. The pointersfunction as follows:

CBR_Current_time

This pointer is generated by a counter in the tx phy FSM 134 and pointsto location 0 of the CBR schedule table 176 after initialization. Itadvances by one schedule table entry 400 every time a cbr cell istransmitted from the tx data FIFO to the PHY interface, and thusadvances at a maximum rate equal to the STS-3c/STM-1 line rate. It wrapsat the end of the ABR/UBR portion of the schedule table (4K entries).The SAR controller 62 never actually accesses the CBR schedule tableentry 400 pointed to by the CBR_current_time pointer.

ABR_Current_time

This pointer is generated by a counter in the tx phy FSM 134 and pointsto location 0 of the ABR schedule table 178 after initialization. Itadvances by one schedule table entry 402 every time an ABR/UBR cell istransmitted from the tx data FIFO to the PHY interface, and thusadvances at a maximum rate equal to the STS-3c/STM-1 line rate. It wrapsat the end of the ABR/UBR portion of the schedule table (4K entries).The SAR controller 62 never actually accesses the schedule table entrypointed to by the ABR_current_time pointer.

ABR Schedule_time

This pointer is generated by the tx rate scheduler FSM 120 and points tolocation 0 of the ABR schedule table after initialization. It isadvanced by the tx rate scheduler 120 through successive locations inthe ABR schedule table 178 at a rate much faster than theABR_current_time pointer; as herein implemented, about 1.2 times fasterthan STS-3c/STM-1 line rates. The ABR_schedule_time pointer thereforeoften represents a point in time which is ahead of the point in timerepresented by the current time counter. As herein embodied, it willnever be allowed to be more than 32 locations ahead of theABR_current_time pointer. The tx rate scheduler FSM 120 reads theabr_head 418 and abr_tail 420 fields of the abr entry 402 at thelocation 404 pointed to by the ABR_schedule_time pointer. This pointerwraps at the end of the ABR schedule table 178; i.e. at 4K.

CBR schedule time

This pointer is generated by the tx rate scheduler FSM 120 and points tolocation 0 of the CBR schedule table after initialization. It isadvanced by the tx rate scheduler 120 through successive locations inthe ABR schedule table 178 at a rate much faster than theCBR_current_time pointer; at least 1.2 times faster than STS-3c/STM-1line rates. The CBR_schedule_time pointer therefore often represents apoint in time which is ahead of the point in time represented by thecurrent time counter. As herein embodied, it will never be allowed to bemore than 32 entries ahead of the ABR_current_time pointer. This pointerwraps at the end of the ABR schedule table; i.e. at 4K.

CBR_sch

This pointer is generated by the tx rate scheduler FSM 120 and points tolocation 0 of the CBR schedule table after initialization. It isadvanced by the tx rate scheduler 120 at the same rate as theCBR_schedule_time pointer. The tx rate scheduler FSM 120 reads the cbrentry 400 in one of the CBR columns (either CBR1 (408) or CBR2 (410)) atthe location pointed to by the CBR_sch pointer. This pointer wraps atthe end of the variable-length CBR portion of the CBR schedule table174.

Cbr_curtime and abr_curtime hereinafter refer to the position of (or thevalues held in) the CBR_current_time and ABR_current_time pointersrespectively, whereas cbr_sch refers to the position of the cbr_schpointer, cbr_sch_time refers to the position of the CBR_schedule_timepointer and abr_sch_time refers to the position of the ABR_schedule_timepointer.

Separate CBR_current_time and ABR_current_time pointers are used whenGFC is enabled, as will be further described. When GFC is disabled, onlya single current_time pointer need be used. In this case, abr_curtimewill take on the same value as cbr_curtime.

As will be seen, the schedule table 174 and the above described pointersprovide a mechanism for ensuring that data for a given VC is transferredfrom the tx data FIFO 132 at the rate that was intended for the VC whenentries for the VC were written into the schedule table 174. Forexample, valid entries 402 for a given ABR VC are placed in the ABRschedule table 178 at intervals corresponding to the rate at which theyshould be transmitted. The entries 402 are read from the ABR scheduletable 176 at locations pointed to by the ABR_schedule_time pointer. Datatransfers are initiated from the host memory 22 to the tx data synchFIFO 128, and ultimately to the tx data FIFO 132, in response to theentries read. Since the ABR_schedule_time pointer leads theABR_current_time pointer, data can reside in the tx data FIFO 132 by thetime the ABR_current time pointer reaches the same location at which theABR_schedule_time pointer pointed when the corresponding entry 402 wasread. Thus, as will be seen, the tx PHY FSM 134 transfers cell data fromthe tx data FIFO 132 to the PHY interface 80 when the ABR_current_timepointer reaches the value that the ABR_schedule_time pointer held whenthe data DMA transfer was initiated. In this way, cell data leaves thetx data FIFO 134 at the rate that was intended for the VC when theentries for the VC were placed at intervals in the ABR schedule table178.

The tx rate scheduler 120 and tx DMA scheduler 122 operate generally asshown in the high level flow diagram of FIG. 21. The tx rate scheduler120 first checks for an abr entry 402 at abr_sch_time; that is, at thelocation presently pointed to by the ABR_schedule_time pointer (step450). If a valid entry 402 exists here (step 452), the list indicated bythe ABR_head 418 and ABR_tail 420 pointers of the entry 402 is appendedto the end of the worklist (step 454). If no valid entry 402 existshere, step 454 is skipped. The tx rate scheduler 120 then checks the CBRschedule table 176 at cbr_sch_time (step 456). If a valid cbr entry 400exists here, (step 458), the tx rate scheduler 120 initiates a datatransfer of data from the host memory 22 to the tx data synch FIFO 128and on to the tx data FIFO 134 by invoking the tx DMA scheduler 122 togenerate a DMA request to be placed in the DMA request FIFO 125 (step460).

If no valid entry exists at this location in the CBR schedule table(step 458), the tx rate scheduler 120 then checks to see if ABR DMAscheduling is allowed. (step 461). If so, the tx rate scheduler 120checks to see if an entry exists in the worklist 428 (step 462). If so,the tx rate scheduler 120 reads the head of the worklist 428 (step 464)and initiates a data transfer for the VC at the head of the worklist 428by calling the tx DMA scheduler 122 to generate a DMA request to beplaced in the DMA request FIFO 125 (step 466). The VC is thenrescheduled into the ABR schedule table 178 (step 468). After a DMArequest is scheduled, or in the event that no valid entry exists ineither the CBR schedule table or the work list, the CBR_schedule_timeand ABR_schedule_time pointers are advanced (step 470) and the processis repeated. The scanning of the schedule table 174 is stalled wheneither the tx DMA request FIFO 125 becomes full or the tx DMA scheduler122 has scanned 32 entries ahead of the “current time” into the scheduletable.

FIGS. 22a-22 j show a flow diagram representing the detailed operationof the tx rate scheduler 120, while FIGS. 23a-23 d show a flow diagramof the operation of the tx DMA scheduler 122. Referring now to FIG. 22a,the tx rate scheduler 120 first checks to see if ABR DMA scheduling ispermitted (steps 472 and 474). If GFC controlled traffic is not enabled,ABR scheduling is permitted if the ABR_schedule_time pointer is withinthe permitted range of the ABR_current_time pointer. Thus, ifabr_sch_time is within 32 cell times of abr_curtime as shown at step472, and if the segmented_fifo signal is in its deasserted state at step474 (indicating GFC controlled traffic is disabled), then ABR DMAscheduling is permitted, and is so indicated by the assertion of thesignal ABR ON (step 476). Else the ABR_ON signal is deasserted (step478).

If GFC controlled traffic is enabled, i.e. the segmented_fifo signal isin its asserted state, then the tx rate scheduler 120 must not onlyensure that abr_sch_time is within the permitted range of abr_curtime,but also that there is room in the abr tx data FIFO 302 to accommodateat least one ABR cell. Thus, as shown at steps 472 and 474, ifabr_sch_time is less than abr_curtime+32, and if there are at least 16long words available in the abr tx data FIFO 302 as indicated by theassertion of the signal fifo_remain≧16LW output from the fifo_remaincounter 316, the ABR_ON signal is asserted (step 476); else ABR_ON isdeasserted (step 478).

If ABR DMA scheduling is permitted, i.e. ABR_ON is asserted, the tx ratescheduler 120 proceeds to read the valid field 422 in the abr entry 402in the ABR schedule table 178 at the location pointed to by the ABRschedule_time pointer (step 480). If the valid bit is set (step 482),indicating a valid ABR entry 402 exists at this location, then the listindicated by the ABR_head and ABR_tail fields 418 and 420 of the entry402 is appended to the tail of the worklist 428.

The worklist 428 is appended as shown in FIG. 22b. First aworklist_valid bit is checked (step 484). If the worklist_valid bit isdeasserted, indicating that no valid entries presently exist in theworklist, then the worklist_head pointer 430 is written with the VCnumber contained in the abr_head field 418 of the ABR schedule tableentry 402 at the location pointed to by the ABR_schedule_time pointer(step 488), and the worklist_tail pointer 432 is written with the VCnumber contained in the abr_tail field 420 of the abr entry 402 at thelocation pointed to by the ABR_schedule_time pointer (step 490). If theworklist_valid bit is asserted, then the worklist 428 is not presentlyempty. In this case, the list indicated by the ABR_head and ABR_tailfields is appended to the tail of the worklist by writing the VC numbercontained in the abr_head field 418 of the entry 402 at the locationpointed to by the ABR_schedule_time pointer to the location in the VCList 180 pointed to by the worklist_tail pointer 432 (step 492), and bywriting the VC number contained in the abr_tail field 420 of the entry402 to the worklist_tail pointer 432 (step 490). In either case, theworklist_valid bit is then set (step 493).

Referring back to FIG. 22a, the tx rate scheduler 120 next checks to seewhether a DMA request for a CBR cell should be placed in the tx DMArequest FIFO 125. If cbr_sch_time is less than cbr_curtime+32 (step494), and if a cbr_inhibit bit (to be further described later) isdeasserted (step 495), the CBR schedule table 176 is read at thelocation currently pointed to by the cbr_sch pointer (step 496).Referring now to FIG. 22c, which shows the cbr handling portion of thetx rate scheduler 120, if the valid bit at this location is asserted,indicating that a valid CBR entry exists here (step 498), then the CBRVC number to be scheduled for DMA is read from the VC field at thislocation (step 500). This VC number is used to index the tx VC statetable 254. The tx rate scheduler 120 then reads the contents of theprescale_count field in the tx VC state table 254 for the VC (step 502).If prescale_count is non-zero (step 504), then the VC may not transmit acell. In this case, prescale_count value is decremented (step 506).

If prescale_count is 0 (step 504), then the tx rate scheduler 120determines whether data is available in host memory 22 for the VC.Accordingly, the Active bit in the tx VC state table 254 for the VC read(step 508). If it is deasserted (step 510), no data exists to betransmitted on this CBR VC, and the tx rate scheduler proceeds toschedule any pending ABR/UBR VCs for DMA in the event that ABRscheduling is allowed (step 512).

If the active bit is set (step 510), data exists in the active slot list162 for the CBR VC. The VC's prescale_count value is then reset to thevalue of prescale_val; that is, the prescale_count field in the tx VCstate table 254 for the VC is written with the value contained in theprescale_val field in the tx VC state table 254 for the VC (step 514).

The tx rate scheduler 120 then determines what value should be passed tothe tx DMA scheduler 122 to be used as the Sched_Time timestamp field inthe DMA request entry to be posted. When GFC is disabled and the tx dataFIFO 132 is not segmented, only a single timestamp need be used; thus,when the segmented_fifo signal is deasserted (step 516), a schedule_timevariable is set to abr_sch_time (step 518). If the segmented_fifo signalis asserted, two separate tx data FIFOs are operating independently andthus their respective entries require independent timestamps; thus, theschedule_time variable for CBR traffic is set to cbr_sch_time (step520), while the schedule_time variable for ABR/UBR traffic will betimestamped with abr_sch_time.

A DMA_request signal is then asserted (step 521), invoking the tx DMAscheduler 122 to post a CBR DMA request entry to the DMA request FIFO125.

Referring now to FIGS. 23a-23 d, the tx DMA scheduler 122 senses theassertion of the DMA_request signal to prepare a DMA request entry forthe DMA request FIFO 125 (step 522). If the request is from the RM cellrequest generator 435 (step 524), the tx DMA scheduler builds an RM cellrequest entry 354 (step 526) and indicates that a cell has beenscheduled for DMA by asserting a cell_sent signal (step 528).

The RM cell request entry 354 fields are written as follows:

VC: from the RM cell request generator FSM 435, the VC on which the RMcell is to be transmitted.

Sched_time: the current value of schedule_time as passed from the txrate scheduler FSM.

RM: 1.

CLP: from the RM cell request generator FSM 435.

FORWARD: from the RM cell request generator FSM 435.

If the request is not from the RM cell request generator FSM 435 (step524), then the tx DMA scheduler 122 has been called from either the cbror abr handling portions of the tx rate scheduler FSM. In this case, thetx DMA scheduler 122 first reads the slot_size field 234 in the slotdescriptor 240 at the head of the tx active slot list 162 for the VC(step 526), and then reads the tx_slot_ptr field 292 in the tx VC statetable 254 for the VC (step 528). If the tx_slot_ptr field is 0 (step530), the beginning of a transmit slot is being processed. The size ofthe DMA transfer to be requested is then determined. If the raw bit 222in the entry at the head of the tx active slot list 162 for the VC isasserted (step 532), then the size of the DMA transfer will be 52 bytes;thus, a DMA_size variable is set to 52 (step 533). If the idle bit 224in the entry at the head of the tx active slot list 162 for the VC isasserted (step 534), then the tx DMA scheduler 122 proceeds to an idlecell processing portion, to be further described.

If the idle bit 224 is deasserted (step 534), then the tx DMA scheduler122 will build a data DMA request entry 350. First determined is thesize of the DMA transfer to be requested. Accordingly, the tx DMAscheduler 122 checks the chtyp field in tx VC state for the VC to see ifthe request is for an MPEG cell (step 536). If it is not, then therequest is for an AAL5 cell, and the size of the DMA transfer isdetermined. The tx_slot_ptr field in tx VC state 254 for the VCindicates the byte position within the current slot from which data iscurrently being DMA'd. Therefore, the size of the DMA transfer to berequested is determined as the minimum of either slot_siz−tx_slot_ptr,or 48 bytes. The DMA_siz variable is set to this value at step 538. Ifat step 536 the request is determined to be for an MPEG cell, then thesize of the DMA transfer depends upon whether the request is for thefinal cell in an 8-cell MPEG superpacket. Therefore, at step 540 theMPEG_count field in tx VC state for the VC is checked. This field wasinitialized to 0 and is updated on the transmission of each cell in an8-cell MPEG superpacket. Thus, if MPEG_count is less than 7, then thesize of the DMA transfer to be requested is determined as the minimum ofeither slot_siz−slot_ptr or 48 bytes, as for a regular AAL5 packet.DMA_size is then set to this value at step 538, and the MPEG_count valueis incremented. If the MPEG_count value is equal to 7 (step 540), thesize of the DMA transfer to be requested is determined as the minimum ofeither slot_siz−slot_ptr, or 40 bytes. The DMA_size variable is setaccordingly at step 542, and MPEG_count is reset.

Once the size of the DMA has been determined, the DMA address from whichdata should be DMA'd is determined by adding the value in slot_ptr tothe contents of the base_address field 238 in the tx active slot list162 for the VC (step 544).

Referring now to FIG. 23b, the Data DMA request entry is built at step546 as follows:

VC: When called from the cbr handling portion of the tx rate scheduler120, the contents of the VC field read from the CBR schedule table entry400 at the location pointed to by the cbr_sch pointer. When called fromthe abr handling portion of the tx rate scheduler 120, the contents ofthe VC field from the entry at the head of the worklist 428.

CBR: the contents of the RC field in the tx VC state table 254 for theVC. When called from the cbr handling portion of the tx rate scheduler,is=1. When called from the abr handling portion of the tx ratescheduler, is=0.

Sched_time: schedule_time as passed from the tx rate scheduler FSM 120.

RM: 0

CLP: the contents of the CLP field in the tx VC state table 254 for theVC

CRC_Ena: 1

DMA_Size: Raw cell: 52 bytes

AAL5/MPEG cell: the contents of the variable DMA_size as determined bythe tx DMA scheduler FSM at steps 538 or 542.

EOP: 1 if the tx slot descriptor for the VC indicates a raw cell and theEOP bit is set, or 1 if the tx VC state table 254 for the VC indicatesan AAL5 or MPEG VC and the EOP bit is set in the VC's tx slotdescriptor, indicating the end of a packet.

Add_MPEG_Trailer: 1 if the chtyp field in the tx VC state table 254 forthe VC indicates an MPEG VC.

DMA_Address: as determined by the tx DMA scheduler 122 at step 544.

INT: raw cell: 1 if the EOP field in the

tx_active slot list for the VC is set.

AAL5 cell: 1 if the end of a slot has been encountered and either theAAL5_SM field in the tx VC state table 254 is set, or the EOP bit in thetx slot descriptor is set.

Once the Data DMA request has been built, it is written to the tail ofthe tx DMA request FIFO 125 (step 548), and the cell_sent bit is set toindicate that a cell is scheduled for DMA (step 550). If the cellscheduled was not a raw cell (step 552), i.e. was an AAL5 or MPEG typecell, the tx_slot_ptr value must be updated. Accordingly, referring toFIG. 23c, DMA_size is added to tx_slot_ptr (step 554). If tx_slot_ptr isnot yet equal to slot_siz (step 556), the entire slot has not yet beenconsumed. The tx_slot_ptr field in tx VC state for the VC is thereforeupdated with the new value of tx_slot_ptr (step 558), and a tds_completebit is set, returning control to the tx rate scheduler FSM (step 560).

If tx_slot_ptr is now equal to slot_siz (step 556), the end of a slothas been encountered (step 561). The transmit slot descriptor 240 isthen moved from the head of the active slot list 162 to the tail of thefree slot list 161 (step 562). The head pointer 243 for the tx activeslot list for the VC is then compared to the tail pointer 242 of the txactive slot list for the VC (step 564). If the pointers are equal, theend of the active slot list has been reached. In this case, the activefield 280 in tx VC state 254 for the VC is reset to 0 (step 566),deactivating the VC from scheduling. The tds_complete bit is then set,returning control to the tx rate scheduler FSM (step 560).

If the head and tail pointers 243 and 242 for the active slot list 254for the VC are determined at step 564 to be unequal, then the headpointer 243 into the tx active slot list for the VC is updated bycopying the link field 241 in the current tx active slot list entry intothe tx active slot list head pointer 243. The tds_complete bit is thenset, returning control to the tx rate scheduler 120 (step 560).

Referring back to FIG. 23a, if the value of tx_slot_ptr as checked atstep 530 is determined to be non-zero, either an idle slot is to beprocessed or processing of an AAL5 or MPEG type slot is to be continued.Accordingly, the tx DMA scheduler 122 checks the idle field 274 in tx VCstate for the VC. If the idle bit is reset, processing of an AAL5 orMPEG slot continues as described from step 536. If the idle field isset, idle slot processing continues from step 572 (FIG. 23d).

Idle cell processing is thus entered at step 572 either from step 570 oras previously described from step 534. At this point, The tx DMAscheduler 122 determines whether an idle slot report request 352 shouldbe generated. If the EOP bit in the tx active slot list 162 for the VCis set, and if the end of a slot has been encountered, then an idle slotreport request 352 is generated. Note that, as for idle cells, the sizeof the DMA request is 0, since no data is actually transferred for idleslots. The Idle slot report request is generated as follows at step 574:

VC: the contents of the VC field read from the CBR schedule table entryat the location pointed to by the cbr_sch_time pointer.

CBR: the contents of the RC field in the tx VC state table 254 for theVC. When called from the cbr handling portion of the tx rate scheduler,is=1. When called from the abr handling portion of the tx ratescheduler, is=0.

RM: 0

DMA Size: 0

The Idle cell report request 352 is then written to the tail of the txDMA request FIFO 125 (step 576). Whether or not an idle cell reportrequest 352 was generated, the tx DMA scheduler 122 then proceeds to setDMA_size to 48; i.e. the size in bytes of an idle cell (step 578).Processing then proceeds from step 554 as previously described.

Referring back to FIG. 22c, the tx rate scheduler FSM 120 awaits theassertion of the tds_complete signal (step 580). Referring now to FIG.22d, if the segmented_fifo signal is deasserted (step 581), alastcell_time parameter is written with the current abr_sch_time (step582), and a lasttime_valid bit is set (step 583). These signals will befurther described later in conjunction with the scheduling of new VCs.The tx rate scheduler 120 then proceeds with the updating of theschedule time pointers.

If, at step 498 (FIG. 22a), no CBR VC is located at the CBR scheduletable entry being read (the valid field of the entry is deasserted), andif ABR_ON is asserted (step 570) indicating that ABR DMA requests arepermitted, then the tx rate scheduler FSM 120 checks the worklist 428 tosee if there is an ABR/UBR VC waiting to generate a DMA request. The txrate scheduler 120 first checks the worklist_valid bit (step 584). Ifthe worklist_valid bit is 0, there are no ABR or UBR VCs waiting for DMAscheduling, so the tx rate scheduler 120 proceeds to update the scheduletable pointers. If the worklist_valid bit is set, the value at the headof the worklist is the VC number to be scheduled for DMA (step 585). Theworklist 428 is then updated. Accordingly, at step 586 the worklist_headpointer 430 is compared to the worklist_tail pointer 432. If thepointers are equal, the worklist 428 is now empty and the worklist_validbit is reset to 0 (step 588). If the pointers are not equal, theworklist_head pointer 430 is updated to point to the next entry in theworklist 428 by writing the value at the location in VC List 180 pointedto by the worklist_head pointer 430 to the worklist_head pointer 430(step 590).

The tx rate scheduler 120 now proceeds to initiate a data transfer fromthe host memory 22 to the tx data synch FIFO 128 and on to the tx dataFIFO 134 by invoking the tx DMA scheduler FSM 122 to schedule a DMArequest. The tx rate scheduler 120 reads the contents of theprescale_count field in the tx VC state table 254 for the VC (step 592).If prescale_count is non-zero (step 594), then the VC may not transmit acell. In this case, the prescale_count value is decremented (step 596),and the VC is rescheduled into the ABR schedule table 178. Accordingly,reschedule_vc bit is set, invoking the rescheduling portion of the txrate scheduler 122. A parameter “t” is set to 4K, indicating the numberof locations from current schedule time at which the VC should bere-entered into the ABR schedule table 178. The value of 4K effectivelyreschedules the VC at the same location in the ABR schedule table 178.The tx rate scheduler 122 then waits at step 600 for the assertion of areschedule_done bit from the rescheduling portion of the tx ratescheduler (to be further described later), and then proceeds to updatethe schedule table pointers.

If the prescale_count value as checked at step 594 was found to be 0,then the tx rate scheduler 120 determines whether data is available inhost memory 22 for the VC. Accordingly, the active bit 280 in the tx VCstate table 254 for the VC read (step 602). If it is deasserted (step604), no data exists to be transmitted on this ABR/UBR VC, so the schbit 282 in tx VC state for the VC is reset to 0 (step 606), indicatingthat this VC is not currently scheduled in the ABR schedule table 178.If the active bit is asserted, the tx rate scheduler 120 proceeds toschedule an ABR/UBR VC for DMA.

Referring now to FIG. 22f, before the VC is scheduled for DMA, theprescale_count field in the tx VC state for the VC is reset to itsinitial value. Each VC has associated with it a value delta_T whichrepresents the time in number of cells, and therefore in number oflocations or rows 404 in the ABR schedule table 178, by which successivecells on a VC are to be transmitted. In the case of an ABR VC, the valueof delta_T is derived from the current ACR (Allowed Cell Rate) for theVC, which is read from the ABR value table for the VC. In the case of aUBR VC, the value of delta_T is derived from the peak cell rate, whichis read from the abr parameter table 122 for the VC. The prescale_countfield in tx VC state for the VC is written with the integer portion ofdelta_T divided by the size of the schedule table 178; herein, theinteger portion of delta_T divided by 4096 (step 608). The prescale_cntfield then effectively holds the number of times the rate scheduler 120should cycle through the schedule table 178 before scheduling the VC forDMA.

The rate scheduler next sets the schedule_time parameter to abr_sch_time(step 610). This value is to be passed to the DMA scheduler FSM 122 tobe written as the timestamp portion of any data or RM cell requests. TheDMA_request signal is then asserted (step 612), invoking the DMAscheduler FSM to post a DMA request to the DMA request FIFO 125. Therate scheduler 120 then waits for the tds_complete signal from the DMAscheduler 122 (step 614), indicating that the request has beensuccessfully posted.

Referring to FIGS. 23a-23 d, the DMA request is built by the tx DMAscheduler FSM 122 in the same manner as was previously described inrelation to the CBR handling portion of the tx rate scheduler FSM.However, when a data DMA request entry is built (FIG. 23b step 546), theCBR field in the data DMA request entry is set to 0 when called from theABR handling portion of the tx rate scheduler 120. Likewise, the CBRfield in an idle slot report request entry is also set to 0 when calledfrom the ABR handling portion of the tx rate scheduler 120 (FIG. 23dstep 574).

Referring back to FIG. 22f, upon detecting the assertion of thetds_complete signal (step 614), the signal DMA_request_on_abr isasserted (step 616). This signal is used to decrement the fifo_remaincounter 317 as previously described. The tx rate scheduler 120 then setsthe value in a lastcell_time register to abr_sch_time (step 618), andthen sets a lasttime_valid bit (step 620). The lastcell_time registerstores abr_sch_time for the last ABR cell scheduled for DMA, and thelasttime_valid bit indicates that the value in the lastcell_timeregister is valid. The lastcell_time register and the lasttime_valid bitare used by the rate scheduler FSM when scheduling new VCs into theschedule table, and will be further described later in conjunctiontherewith.

After scheduling the ABR DMA request, the tx rate scheduler 120 callsthe rescheduling portion of the tx rate scheduler 120 to reschedule theVC into the ABR schedule table. Accordingly, a reschedule_vc signal isasserted, and a value “t” is passed which indicates the position in theschedule table 178 at which the VC should be appended (step 622). Thedelta_T value for the VC is first prescaled as previously described byperforming the function (delta_T/table_size), where table_size is thesize of the ABR schedule table 178, herein 4096. The remainder of thefunction then gives the position in the ABR schedule table 178 relativeto abr_sch_time at which the VC should be appended, while the integerportion of the function is written as the prescale_cnt value in tx VCstate for the VC (FIG. 22f step 608). It is the remainder portion of thefunction that is passed to the rescheduler portion of the tx ratescheduler 120 as the parameter “t”.

Note that when the tx DMA scheduler 122 issues a DMA request for an ABRor UBR VC, it will reschedule the VC in the schedule table whether ornot the VC has any data left to send. This means that an ABR or UBR VCat the head of the worklist 428 may in fact have no data available forfetching. If this event occurs, the active condition check at step 604will fail. The VC will be taken off of the work list, it will not berescheduled, and the sch bit will be cleared in the tx VC state table254 for the VC to indicate to the rate scheduler FSM that the VC is nolonger scheduled for transmission. When, at some point in the future,the host posts a tx slot for the VC, the VC will be placed at the tailof the worklist 254 (as will be further described) and the sch bit willbe set.

The rescheduling portion of the rate scheduler FSM reschedules VCs intothe ABR schedule table either in the event that the prescale_cnt valuefor the VC was zero, or in the event that a DMA request has beengenerated for the VC. Referring to FIG. 22j, the rescheduler portion ofthe tx rate scheduler FSM 120 awaits the assertion of the reschedule vcsignal (step 624). When the signal is asserted, the tx rate scheduler122 accepts as input a VC number and a time value “t”. For VCs for whichthe prescale count was non-zero, “t” is set to 4K (FIG. 22e step 598),effectively rescheduling the VC at the location in the ABR scheduletable currently being processed. For VCs for which the prescale countwas non-zero, “t” may be any value between 1 and 4K, and is determinedas previously described as the remainder of the function delta_T mod4096 where delta_T is determined according to the ABR parameterscurrently in effect, as calculated from values read from the ABRparameter and value tables (FIG. 22f step 622).

A value T, calculated as T=(abr_sch_time+t) mod table_size (step 625),represents the new location in the ABR schedule table at which the VCshould be rescheduled, and is therefore used as an index into the ABRschedule table 178. First, the valid bit 422 of the abr entry 402 atlocation T in the ABR schedule table 178 is read (step 630). If thevalid bit 422 is deasserted, then there are no VCs currently scheduledat the time represented by the location T. In this case, the abr_headand abr_tail fields 418 and 420 for the entry 402 at location T are setto the VC (step 632, 634), and the valid bit 422 is set (step 636).

If the valid bit 422 is set (step 630), then there are other VCs waitingto transmit cells at the time T. In this case, the VC is added to thehead of the list of VCs scheduled to transmit cells at the time T.Accordingly, the contents of location vc in the VC list 180 is writtenwith the contents of the abr_head field 418 of the entry 402 at locationT (step 638), and the abr_head field 418 of the entry 402 at location Tis then written with the VC number (step 640). In either case, areschedule_done bit is set (step 642) to indicate completion ofrescheduling.

Rescheduling VCs at the head of the ABR schedule table list rather thanat the tail of the list results in a performance advantage. High rateVCs are typically more sensitive to cell latency than lower rate VCs,and high rate VCs are rescheduled more often than lower rate VCs. Byrescheduling VCs at the head of the list, the cells for high rate VCsare more likely to be transmitted at the scheduled time; therefore, thetraffic for the high rate VCs will tend to comply more closely with theACR for the VCs.

Note also that this concept can be useful in any application whichutilizes a schedule memory (i.e. the schedule table 174) for storingentries at locations, each of which represent a point in time at which adata unit is to be transmitted. The concept is particularly useful wherecertain data units to be scheduled for transmission are members of arelatively high rate group. Wherever there is provided a schedulememory, each of whose entries contain a pointer pointing to a datastructure containing data units (of any sort) scheduled for transmissionat a time corresponding to the location of the entry in the schedulememory, and a new data unit is to be added to the data structure to betransmitted at a particular time, a performance advantage can beobtained if the scheduler (such as tx rate scheduler 120) write s thedata unit to the data structure such that the data unit is the first ofthe data units in the data structure to be transmitted.

New ABR/UBR VC Scheduling

Recall that when a new ABR/UBR VC is s e t up by the host driver 24, thedriver 24 sets up the tx VC state table 254 for the VC and writes txslot descriptors 240 for the VC to the tx pending slot FIFO 200.Referring now to FIG. 23e, when the tx pending slot FIFO 200 indicatesto the tx DMA scheduler 122 that a slot is available (step 644), the txDMA scheduler 122 pops an entry from the head of the FIFO (step 646),obtaining a VC number from the VC field of the entry. The tx DMAscheduler then increments the tx pending slot FIFO head pointer 182(step 648). The parameter num_word count, used as previously describedby the tx pending slot controller 186, is decremented by 2 (step 650),and the entry_avail signal is asserted (step 652), indicating that thereis room in the tx pending slot FIFO 124 to accept another descriptorfrom the host system 14. The tx DMA scheduler 122 then reads the schfield in the tx VC state table 254 for the VC to determine whether theVC is already scheduled in the ABR schedule table (step 654). If the schbit is asserted (step 656), the n the VC is already scheduled and aschedule_new_vc signal remains deasserted (step 658). If the sch bit isdeasserted, then the VC needs to be scheduled into the schedule table bythe tx rate scheduler 120. The schedule_new_vc signal is asserted (step660) to invoke this process. The tx DMA scheduler 122 then awaits theassertion of a trs_ack signal (step 662), indicating that the tx ratescheduler has completed the process of scheduling the new VC.

In either case, referring to FIG. 23f, the tx DMA scheduler thende-queues a tx slot descriptor 240 from the free slot list 161 (step664), writes the contents of the tx pending slot FIFO entry just readinto the tx slot descriptor 240 (step 666), and then queues the tx slotdescriptor 240 to the active slot list 162 for the VC (step 668).

Referring now to FIG. 22i, there is shown the process undertaken by thetx rate scheduler 120 for scheduling new VCs into the ABR schedule table178. Scheduling of new VCs is handled differently than rescheduling ofalready scheduled VCs for the following reason. Recall that theABR_schedule_time pointer advances through the ABR schedule table at afaster rate than the ABR_current_time pointer, and can advance up to 32locations ahead. If no other VCs are scheduled between abr_curtime andabr_sch_time, the new VC should be scheduled for immediate transmission.However, if the new VC is simply scheduled at abr_sch_time andtimestamped as such when a DMA request is posted (i.e. the DMA requestentry Sched_time field is set to abr_sch_time), its transmission will bedelayed by a number of cell times equal to the difference betweenabr_curtime an abr_sch_time, which may be up to 32 cell times.

This unacceptable latency in the transmission of new VCs is avoided byappending the new VC directly to the tail of the worklist. Accordingly,referring to FIG. 22h, if no out-of-rate RM cells are pending (to befurther described) (step 670), the tx rate scheduler 120 awaits theassertion of the schedule_new_vc signal (step 672) by the tx DMAscheduler 122, which indicates that a new VC should be scheduled in theABR schedule table. If the worklist_valid bit is reset (step 674),indicating that the worklist is empty, the worklist_head andworklist_tail pointers 430 and 432 are written with the VC number (steps676, 678). Otherwise, if the worklist_valid bit is set, (step 674), theVC is appended to the end of the worklist by first writing the contentsof the VC list 180 at the location pointed to by the worklist_tailpointer 432 to the VC (step 680), and then updating the worklist_tailpointer with the new VC (step 678). Thus, if the worklist is empty whenthe new VC is scheduled (and it most likely is in the event thatabr_sch_time has advanced in time beyond abr_curtime), the new VC willbe transmitted immediately (provided there is no CBR traffic to betransmitted at the same time.) The tx rate scheduler 120 then sets atrs_ack signal (step 684), indicating to the tx DMA scheduler 122 thatnew VC scheduling has been completed.

The tx rate scheduler 120 will now back up abr_sch_time to point to alocation immediately following the time at which a DMA request for anABR VC was last generated. This is done for two reasons.

First of all, recall that when a data DMA request entry 350 is producedfor the VC at the head of the worklist 482, the Sched_time field iswritten with abr_sch_time. That is, abr_sch_time is used as thetimestamp to indicate to the tx phy FSM 134 the time at which the ABRcell associated with the request should be transmitted. Therefore, ifabr_sch_time is not reset, the timestamp associated with the new VC willbe up to 32 cell times later than necessary, thereby adding needlesslatency to cell transmission.

Secondly, high-rate VCs will call for scheduling only a small number ofcell times apart. However, as previously described, after the new VC isappended to the worklist 482, it rises to the head of the worklist, aDMA request for the new VC is generated, and the VC is rescheduledrelative to abr_sch_time. Consider now the case where theABR_schedule_time pointer points at a location 32 cell times fromabr_curtime. The new VC is appended to the end of the worklist and thenis rescheduled at a time delta_T=2. If abr_sch time is not backed up,the rescheduled VC will not be scheduled for DMA until abr_sch_time+2;i.e. 34 cell times in the future rather than the intended 2 cell times,again adding needless latency to cell transmission. Abr_sch_time istherefore reset in the following manner. Recall that the tx ratescheduler FSM 120 at step 618 (FIG. 22f) provides a lastcell_timevariable which stores the abr_sch_time at which the last DMA request foran ABR/UBR VC was generated. A lasttime_valid bit (step 620) indicatesthat the value held in lastcell_time is valid. As long as the value inlastcell_time is greater than abr_curtime−that is, abr_curtime has notyet passed the location at which the last cell was scheduled—thenlastcell_time is valid, and abr_sch time should take on the value oflastcell_time +1. The lasttime_valid bit is reset when abr_curtimereaches lastcell_time. In this case, abr_sch_time should take on thevalue of abr_curtime+1.

Thus, as shown then in FIG. 22i, the tx rate scheduler 120 saves thecurrent value of abr_sch_time in a lastabr_time register (step 686). Thefunction of this parameter is described later. Then, if thelasttime_valid bit is set (step 688), abr_sch_time is reset to thelocation (or time) immediately following the value held in lastcell_time(step 690). If the lasttime_valid bit is not set, abr_sch_time is resetto the time indicated by abr_curtime+1 (step 692).

Note that, as an alterative to the previously described process in whichthe new VC was appended to the tail of the worklist 428, the new VCcould be inserted at the head of the ABR schedule table list located atlastcell_time +1 (or abr_curtime+1) rather than at the tail of theworklist to achieve the same result. This alternative costs an extralocal memory access to append the ABR schedule table 178 entry 402 tothe worklist 428.

Out-of-rate RM cells (ORM cells) are not scheduled for DMA via theworklist 428; rather, the RM cell request generator (FIG. 6) 435 buildsPM cell request entries 354 (FIG. 19c) in accordance with the raterequirements in effect for the VCs with which they are associated, andwrites them directly to the tx DMA FIFO 125. As shown in FIG. 22i, ORMcells are arbitrarily scheduled with priority over new VCs. ORM cellsare transmitted at no more than 10 cells/s; thus, priority scheduling ofthese cells expends minimal bandwidth while avoiding ORM cell clumping.As ORM cells are scheduled for DMA (step 670), the lasttime_valid bit ischecked and abr_sch_time is reset to lastcell_time or abr_curtime aspreviously described (steps 688-692).

Once abr_sch time is reset to either lastcell_time or abr_curtime, thesegmented_fifo signal is checked (step 694). If it is asserted, acbr_inhibit signal is asserted (step 696); else, the cbr_inhibit signalremains deasserted (step 698). The function of this signal is furtherdescribed later. The new VC scheduling portion of the tx rate schedulerthen returns to await the scheduling of an ORM cell or new vC.

At this point, th e tx rate scheduler FSM 120 has either posted a CBRDMA request, or, if no CBR entries were scheduled in the CBR scheduletable, an ABR DMA request, or, if there were no entries in the worklist428, no request. It is now time to increment the schedule time pointersand repeat the process.

Referring to FIG. 22g, the tx rate scheduler 120 checks the segmentedfifo signal (step 700). If it is asserted, cbr_sch_time is incremented(step 702). When the tx rate scheduler 120 read the CBR schedule tableentry at step 496 (FIG. 22a), it retained the value of the EOT bit forthat entry. This bit is now checked (step 704). If it is set, indicatingthat the end of the CBR schedule table 176 has been reached, the cbr_schpointer is reset to 0 (step 706). Otherwise, the cbr_sch pointer isincremented (step 708).

If ABR DMA scheduling is permitted, as indicated by the assertion ofABR_ON (step 710), abr_sch_time is also incremented (step 712).Abr_sch_time is then compared to lastabr_time (step 714), and if equal,the cbr_inhibit signal is reset (step 716). Abr_curtime is then comparedto lastcell_time (regardless of whether ABR_ON is set) (step 718), andif they are equal, lasttime_valid is reset (step 720).

If at step 700 the segmented_fifo signal is found to be deasserted, thecbr_inhibit signal is checked (step 722). Recall that the cbr_inhibitsignal is asserted by the new VC scheduling portion of the tx ratescheduler 120 at step 694 (FIG. 22i).

The cbr_inhibit signal serves the following purpose. Recall that, whenthe segmented_fifo signal is deasserted, abr_sch_time is used by the cbrhandling portion of the tx rate scheduler 120 as the timestamp portionof data DMA requests and idle slot report requests. When the tx ratescheduler 120 schedules a new VC, abr_sch_time is backed up aspreviously described. If the cbr_sch pointer is allowed to continueadvancing after this occurs, successive timestamps could be lower invalue than previous ones already scheduled, thereby causingperturbations on the constant bit rate channel. Furthermore, if thecbr_sch pointer is merely prevented from advancing, the same entry willbe read from the CBR schedule table 176 on each scan of the table 176 bythe tx rate scheduler 120. This could cause incorrect decrementing ofthe prescale_count value for the VC associated with the entry beingread, and thus incorrect cell generation.

The cbr_inhibit signal is therefore used to prevent operation of the cbrhandling portion of the tx rate scheduler 120 until abr_sch_time hascaught up to its previous value, which was saved in the lastabr_timeregister. Recall that at step 495 in FIG. 22a the CBR schedule table 176was not accessed unless the cbr_inhibit bit was reset.

Accordingly, referring back to FIG. 22g, abr_sch_time is compared to thecontents of the lastabr_time register (step 714). If the values areequal, abr_sch_time has caught up to the point from which it was reset,cbr_inhibit is reset (step 716), and the CBR_schedule_time and cbr_schpointers are then incremented on further passes through the tx ratescheduler 120. Otherwise, cbr_inhibit remains set and incrementing ofthe CBR_schedule_time and cbr_sch pointers is inhibited untilabr_sch_time has caught up to the point from which it was reset.

After the schedule time pointers are incremented, cbr_sch_time iscompared to cbr_curtime (step 722). If they are equal, a set_stopcnt_cbrsignal is asserted (step 724); else this signal is deasserted (step726). Likewise, abr_sch_time is then compared to abr_curtime (step 728).If they are equal, a set_stopcnt_abr signal is asserted (step 730); elsethis signal is deasserted (step 732). These signals are used by the txphy FSM 134 to control the advancement of the CBR_current_time andABR_current_time pointers, as will be further described in conjunctionwith that machine. The tx DMA scheduler 122 then returns to its initialstate.

The schedule table 174 and current_time and schedule_time pointerspreviously described provide a mechanism for ensuring that data for agiven VC is transferred from the tx data FIFO 132 at the rate that wasintended for the VC when the entries for the VC were written into theschedule table 174. This is accomplished by providing a schedule timepointer that leads in time ahead of a current time pointer, and byinitiating data transfers from host memory to (ultimately) the tx dataFIFO based on information obtained from the schedule table at locationspointed to by the schedule time pointer. Then, despite system buslatencies, the cell data for a given VC will reside in the transmitbuffer memory (tx data FIFO 132) by the time the current_time pointerreaches the time at which the VC was scheduled. The data can then betransmitted when the current_time pointer reaches the time in theschedule table at which the VC was scheduled.

It should be noted that the scheduling mechanism herein described isuseful in any type of environment requiring the transfer of data from asource memory to a transmit buffer memory and then on to an interface.Though the source memory herein described is a host memory 22, thescheduling mechanism could easily operate to transfer data from memoryon a different node to an interface, or from memory on one adapter tomemory on another adapter (i.e. peer-to-peer memory) and then to aninterface. On the other hand, the source memory, transmit buffer memory,and interface may all reside on the same system module. Moreover, thoughthe transmit buffer memory herein described is the tx data FIFO 132, andthe interface is a network interface, the scheduling mechanism may beeasily employed to transfer data from a source memory to any buffermemory residing between the source memory and any type of interface;e.g. a data storage buffer coupled to a disk drive interface, a videobuffer coupled to a graphics interface, or the like.

Tx Data synch fifo 128

The entries which were placed in the DMA request FIFO 125 by the tx DMAscheduler 122 are now read by the tx DMA FSM 126, which processes eachentry and initiates the appropriate DMA requests to move cell data fromhost memory 22 to the tx data synch fifo 128. According to the preferredembodiment, the tx data synch fifo 128 is implemented as a 16 LW deepFIFO, which provides adequate buffering for the maximum transmit DMAburst of 13 LW which the controller may perform, in addition to alongword of control information for each burst.

Referring to FIG. 24, when the tx DMA FSM 126 processes a DMA requestfor a new cell, it creates a 4-byte txsf start of cell (SOC) controllongword 738 (txsf SOC LW) which it places in the tx data synch fifo 128in order to provide the tx cell FSM 130 information about the request.AAL5 cells are stored as the 4-byte txsf SOC LW 738 followed by 48 bytesof data (unless the AAL5 cell spans two slots, as will be furtherdescribed in conjunction with the tx cell FSM 130). Raw cells are storedas the 4-byte txsf SOC LW 738 followed by 52-bytes of data (the entirecell excluding the HEC). Each RM cell request in the tx DMA request FIFO125 results in the creation of a single txsf SOC LW with no subsequentdata in the tx data synch fifo 128. Idle cell requests do not result inany entries being placed in the tx data synch fifo 128, nor in the DMAof any data.

All of the fields in the txsf SOC LW 738 are simply copied directly fromthe corresponding fields in the tx DMA request FIFO 125 entries. Thevarious fields of a txsf SOC LW 738 are shown in FIG. 24 and describedas follows:

VC (740)

This 12-bit field specifies the VC with which the cell is associated.

Sched_time (742)

This 8-bit field contains the time at which the tx DMA scheduler 122issued the request for the cell.

RM (744)

This 1-bit field indicates if the txsf SOC LW is an RM cell request(RM=1) or the beginning of a raw or AAL5 cell (RM=0).

CLP (746)

This 1-bit field contains the CLP bit to be inserted into the cellheader of the transmitted cell for AAL5 cells or RM cells.

CRC_Ena/Forward (748)

For non-RM SOC entries, this 1-bit field when set indicates that a CRCmust be computed across the data DMA'd as a result of the request. Ifthe request is for a raw cell (as indicated by the raw bit), then thisbit indicates that a CRC-10 will be computed and inserted in the rawcell transmitted as a result of the request. If the request is for partof an AAL5 packet then this bit indicates that a CRC-32 should becomputed across the data DMA'd and transmitted as a result of therequest.

For RM SOC entries, this bit indicates whether the RM cell createdshould be a forward (forward=1) or backward (forward=0) RM cell.

Raw (750)

This 1-bit field indicates whether the cell following the SOC controllongword is an AAL5 cell consisting of 48 bytes of data or a raw cellconsisting of 52 bytes of data.

EOP (752)

This 1-bit field indicates if the cell following the txsf SOC LWcontains the last byte of an AAL5 packet. It's value is significant onlywhen the Raw bit is cleared. This bit will be used to determine thevalue of the EOM bit of the PT field for AAL5 packets, and to overwritethe driver 24-provided AAL5 CRC placeholders with the computed CRCs inthe last cells of AAL5 packets.

Add_MPEG_Trailer (754)

This 1-bit field indicates if the AAL5 packet being segmented is an MPEGsuper packet and if the txsf SOC LW describes the last cell in a set of2 MPEG PDUs (transmitted in a single AAL5 packet). This bit indicatesthat the tx cell FSM 130 should append the MPEG trailer (AAL5 Control=0,AAL5 length=376, AAL5 CRC) to the end of the data in the tx data synchfifo 128 when moving the data into the tx data FIFO 132.

CBR (756)

This 1-bit field indicates whether the request is associated with a CBRor ABR VC, and is used when GFC is enabled in order to direct the dataassociated with the request to the appropriate cbr or abr tx data FIFO300 or 302.

In the actual implementation, the eop and add_mpeg_trailer bits are notactually placed in the tx data synch fifo 128, but rather are held inflops. This is because these 2 bits which describe a cell are not validuntil the last DMA request out of several requests which may make up acell (for AAL5 cells). The txsf SOC LW entry is written at the time ofthe first request, but since the 2 bits are not valid until the lastrequest, they are stored in flops and multiplexed with the FIFO outputfor consumption by the tx cell FSM 130.

Tx DMA FSM 126

The tx DMA FSM 126 serves as the interface between the tx DMA requestFIFO 125, the PCI bus 18, and the tx data synch fifo 128. The tx DMA FSM126 performs the following functions:

reads entries from the tx DMA request FIFO 125;

generates DMA requests for cell data transfers from the host 14 to theSAR controller 62 via the PCI bus 18 when required;

generates a txsf SOC control longword 738 for each entry;

writes the txsf SOC control longwords 738 and cell data to the tx datasynch fifo 128.

The operation of the tx DMA FSM 126 is shown in the flow diagram ofFIGS. 25a-25 b. When the tx DMA FSM 126 detects that the tx DMA requestFIFO 125 contains at least one entry (step 760), and through handshakingwith the tx cell FSM 130 verifies that the tx data synch fifo 128 iseither empty or will be emptied in the near future (step 762), it popsan entry off the head of the DMA request FIFO 125 (step 764). If theentry popped off the DMA request FIFO 125 is not an idle slot reportrequest 352, the tx DMA FSM 126 builds a txsf SOC LW 738 (txsf SOC LW)based on the contents of the tx DMA request FIFO 125 entry popped (step768), and writes it to the tx data synch fifo 128 (step 770).

The EOC bit for the entry is then checked (step 772). If the DMA burstis for a new cell which is to be transferred via a single DMA request,the EOC bit in the DMA request FIFO 125 entry will be set. In this case,a txsf_SOC_rdy bit is set to indicate to the tx cell FSM 130 that avalid txsf SOC LW entry exists in the tx data synch fifo 128 (step 774).When the tx DMA FSM 126 detects that a request in the tx DMA requestFIFO 125 is an RM cell request (step 776), it places a txsf SOC LW entryin the tx data synch fifo 128 requesting that an RM cell be built andtransmitted but does not DMA any data from host memory 22.

If the request is for a data cell rather than an RM cell (step 776), aDMA request is posted to a DMA arbiter (step 782), which arbitratesbetween the various processes that contend for the PCI bus 18. When thearbiter grants PCI access to the tx DMA FSM 126 (step 784), the FSM usesthe DMA_base_addr and DMA_size fields of the DMA request FIFO 125 entryto burst data for a cell from host memory 22 into the tx data synch fifo128 (step 786). For requests to DMA data from raw cell slots, exactly 52bytes of data will be transferred across the PCI bus 18. For requests toDMA data from AAL5 slots, 1 to 48 bytes of data will be transferredacross the PCI bus 18. Upon completion of the data transfer (and oncompletion of the construction of an RM cell header at step 780), atxsf_data_rdy bit is set (step 788) to indicate to the tx cell FSM 130that a cell is available in the tx data synch fifo 128 for transfer tothe tx data FIFO 132.

The tx DMA FSM 126 now checks to see whether a tx status report shouldbe generated (step 790). A tx status report is generated forend-of-packet (EOP) slots or for AAL5 slots in which the tx_AAL5_SM bitis set in tx VC state for the VC. if no tx status report is due, the txDMA FSM 126 returns to process the next entry in the tx DMA request FIFO125. Otherwise, a DMA request is posted to the DMA arbiter (step 792),and, when PCI bus access is granted (step 794), a tx status longword istransferred to the tx status report queue in host memory 22 (step 796).

In the case where the tx DMA FSM 126 must fetch an AAL5 cell whichstraddles a slot boundary, it must do so in 2 or more separate DMArequests. In this case, the EOC bit in the tx DMA request FIFO 125 entrywill be set only for the entry containing the final byte of data to betransferred. The first request will result in the creation of the txsfSOC control longword in the tx data synch fifo 128, but the tx DMA FSM126 will not be informed of the availability of the SOC longword untilthe request for the last byte of data in the cell is issued.Accordingly, if EOC is not set (step 722), A DMA request is posted tothe DMA arbiter (step 800), and, when the arbiter grants PCI access tothe tx DMA FSM 126 (step 802), the tx DMA FSM 126 bursts data for a cellfrom host memory 22 into the tx data synch fifo 128 (step 804). Theprocess repeats (steps 806, 808, 810, 772, 800, 802, 804) until the EOCbit for an entry is set (step 722). The txsf_SOC_rdy bit is then set(step 774), the DMA request is posted (step 782), the DMA transfer iscompleted (steps 784, 786), and the txsf_data_rdy bit is set (step 788).

Tx data FIFO 132

The tx data FIFO 132 serves as the transmit buffer memory for thesegmentation engine 88. The tx data FIFO 132 is written by the tx cellFSM 130 and read by the tx phy FSM 134. The tx data FIFO 132 isimplemented according to the preferred embodiment to provide bufferingfor up to approximately 16 cells to be transmitted on the link. As waspreviously described, (FIG. 6), when GFC flow control is enabled, the txdata FIFO indicates such with the assertion of the segmented_fifosignal. The tx data FIFO 132 is then split into two FIFOS capable ofholding 8 cells each—a cbr tx data FIFO 300 for storing uncontrolled CBRcells, and an abr tx data FIFO 302 for storing controlled ABR/UBR cells.

Each data cell in the FIFO is stored as either a 52-byte quantity or a56-byte quantity, depending on whether the cell is an AAL5 cell or a rawcell. AAL5 cells are stored as a 4-byte start of cell control longword(tdf SOC LW) followed by 48 bytes of data, thus consuming 13 LW of spacein the FIFO. Raw cells are stored as a 4-byte tdf SOC LW followed by52-bytes of data (the entire cell excluding the HEC field), thusconsuming 14LW. RM cells are stored as a 4-byte tdf SOC LW followed by 8bytes of RM control information, thus consuming 3 LW. In FIG. 26, the txdata FIFO 132 is shown containing 3 cells: a raw cell 812 at the head ofthe FIFO, followed by an AAL5 cell 814, followed by another raw cell 816at the tail of the FIFO.

The tx data FIFO SOC control longword 818 is shown in FIG. 27. Itsfields are copied from the txsf SOC LW fields as follows:

VC (820)

This 12-bit field specifies the VC with which the cell is associated.

Sched_time (822)

This 8-bit field contains the time at which the tx DMA scheduler 122issued the request for the cell.

RM (824)

This 1-bit field indicates if the cell following the SOC controllongword in the tx data FIFO 132 is an 8-byte RM cell. If this bit isset, the CRC_Ena, Raw and EOP bits have no significance and will beignored.

CLP (826)

This 1-bit field contains the CLP bit to be inserted into the cellheader of the transmitted cell for AAL5 and RM cells. Its value isextracted by the tx DMA scheduler 122 from VC state, and is significantonly when the Raw bit is cleared.

CRC_Ena (828)

This 1-bit field indicates whether or not a CRC-10 is to be calculatedacross the data in a raw cell. Its value is significant only when the RMbit is cleared and the raw bit is set (see below). RM cells will alwayshave the CRC-10 calculated and appended regardless of the value of thisbit.

Raw (830)

This 1-bit field indicates whether the cell following the SOC controllongword is an AAL5 cell consisting of 48 bytes of data or a raw cellconsisting of 52 bytes of data. It's value is significant only when theRM bit is cleared. If the RM bit is set, the data following the tdf SOCLW comprises an 8-byte RM cell.

EOP (832)

This 1-bit field indicates if the cell following the tdf SOC LW containsthe last byte of an AAL5 packet. It's value is significant only when theRM, Raw and Add_MPEG_Trailer bits are all cleared. This bit will be usedto determine if the EOM bit of the PT field of the c ell should be set.

Add_MPEG_Trailer (834)

This 1-bit fie ld indicates if the AAL5 packet being segmented is anMPEG super packet and if the tdf SOC LW describes the last cell in a setof 2 MPEG PDUs (transmitted in a single AAL5 packet). This bit will beused to determine if the EOM bit of the PT field of the cell should beset.

The tx data FIFO 132 keeps track of whether or not it is full, providingthe signals cbr_space_avail and abr_space_avail to the tx cell FSM 130.In the event that the tx data FIFO 132 is in unsegmented mode and it isfull, the cbr_space_avail bit is reset. In the event that the tx dataFIFO 132 is in segmented mode and the cbr tx data FIFO 300 is full, thecbr_space_avail bit is reset. In the event that it is in segmented modeand the abr tx data FIFO 302 is full, the abr_space_avail bit is reset.

Tx Cell FSM 130

The tx cell FSM 130 serves as the interface between the tx data synchfifo 128 and the tx data FIFO 132. The functions of the tx cell FSM 130are generally as follows:

moving of SOC control longword entries from the tx data synch fifo 128to the tx data FIFO 132;

moving of cell data from the tx data synch fifo 128 to the tx data FIFO132;

computation of CRC32 for AAL5 packets, as insertion of CRC32 into AAL5EOP cells;

initialization of the CRC32 value at AAL5 packet boundaries;

delineation of 8-cell MPEG packets and insertion of the AAL5 trailer forsuch packets;

reading of RM cells from the local memory 76 and writing of the RM cellsto the tx data FIFO 132.

FIGS. 28a-28 d describe the detailed operation of the tx cell FSM 130.The tx cell FSM 130 first waits for the txsf_SOC_rdy signal from the txDMA FSM 126 (step 834), indicating that a valid SOC is available in thetx data synch fifo 128. The tx cell FSM 130 reads the txsf SOC LW (step836) and sets the SOC_rd bit (step 838) to indicate to the tx DMA FSM126 that the SOC LW has been consumed. The txsf SOC LW is then decoded(step 840). If either the segmented_fifo signal is deasserted,indicating single FIFO mode, or the segmented_fifo signal is assertedbut the txsf SOC LW CBR bit is set, indicating that the tx data synchfifo 128 holds a CBR cell to be placed in the cbr tx data FIFO 300 (step842), the tx cell FSM 130 checks to see if space is available in the CBRdata FIFO by checking to see if a cbr_space_avail bit from the tx dataFIFO 132 is set (step 844). If so, the tx cell FSM 130 sets a cbr_selectbit (step 846) to enable writing to the cbr tx data FIFO 300. If thesegmented_fifo signal is asserted and txsf SOC LW CBR bit is not set,indicating that the tx synch FIFO holds an ABR/UBR cell to be placed inthe abr tx data FIFO 302 (step 842), the tx cell FSM 130 the tx cell FSM130 sets an abr_select bit to enable writing to the abr tx data FIFO 302(step 850). Note that the tx cell FSM 130 need not check to see if spaceis available in the ABR data FIFO, since the fifo_remain controller 316has already made this determination.

If the decoding of the txsf SOC LW indicates an AAL5 (or MPEG) cellwhich is not an EOP cell (step 852), the tx cell FSM 130 reads the CRCvalue for VC from tx VC state for the VC (step 854). Then if thetxsf_data_rdy bit is set (step 854), indicating that cell data isavailable for transfer from the tx data synch fifo 128, the tx cell FSM130 sets a tcf_strt_rd bit (step 858) to indicate to the tx DMA FSM 126that cell data is being transferred from the tx data synch fifo 128 tothe tx data FIFO 132. The cell data is then moved from the tx data synchfifo 128 to the tx cbr data FIFO is cbr_select is set, or to the abrdata FIFO if abr_select is set (step 860).

The 32 bit CRC for an AAL5 packet is calculated incrementally across thevarious cells making up the packet. Thus, the tx cell FSM 130 calculatesthe new CRC32 value based on the CRC field previously read from tx VCstate (step 854) and on the data transferred, and writes the new CRC32value back to the tx VC state table 254 (step 862).

If the decoding of the txsf SOC LW indicates an AAL5 cell which is anEOP cell (step 864), then the txsf data is handled in the same manner aspreviously described for AAL5 cells. The CRC value for the VC is readfrom tx VC state for the VC (step 866). Then, if the txsf_data_rdy bitis set (step 868), indicating that cell data is available for transferfrom the tx data synch fifo 128, the tx cell FSM 130 sets thetcf_strt_rd bit (step 870) to indicate to the tx DMA FSM 126 that celldata is being transferred to the tx data FIFO 132. The cell data is thenmoved from the tx data synch fifo 128 to the tx cbr data FIFO ifcbr_select is set, or to the abr data FIFO if abr_select is set. The newCRC32 value is then calculated based on the CRC field read from tx VCstate and on the data transferred (step 872), and then written to the txdata FIFO 132 (step 874). The CRC value stored in the tx VC state table254 for the VC is then reset to an initialization value (step 876).

If the decoding of the txsf SOC LW indicates an MPEG cell which is anEOP cell (step 878), then the txsf data is handled in the same manner aspreviously described for AAL5 EOP cells (steps 880-892), except that theMPEG trailer is written to the tx data FIFO 132 prior to writing theCRC32 to the tx data FIFO 132 (step 888).

If the decoding of the txsf SOC LW indicates a RAW cell (step 894), thenif the txsf_data_rdy bit is set (step 896), indicating that cell data isavailable for transfer from the tx data synch fifo 128, the tx cell FSM130 sets a tcf_strt_rd bit (step 898) to indicate to the tx DMA FSM 126that cell data is being transferred from the tx data synch fifo 128 tothe tx data FIFO 132. The cell data is then moved from the tx data synchfifo 128 to the tx cbr data FIFO is cbr_select is set, or to the abrdata FIFO if abr_select is set (step 900). No CRC calculation isrequired for raw cells.

If the decoding of the txsf SOC LW indicates an RM cell (step 902), thetx cell FSM 130 then checks the CRC Ena/Fwd bit (step 908). If this bitis set, the header for a forward RM cell is moved from the local memory76 to the tx abr data FIFO (step 910). If the bit is not set, the headerfor a backward RM cell is moved from the local memory 76 to the tx abrdata FIFO (step 912). Tx VC state for the VC is then checked to see ifthe VC_congestion bit is set (step 914). If so, the bit is reset (step916).

Upon completion of construction of the tx data FIFO 132 entry, the txcell FSM 130 resets the cbr_select, abr_select, tcf_SOC_rd, andtcf_strt_rd bits (step 918). If the FIFO is not segmented or if the FIFOis segmented and the txsf SOC LW CBR bit is set (step 920), a cbr_availsignal is asserted (step 922) to indicate that a cell is available inthe cbr tx data FIFO 300. If the FIFO is segmented and the txsf SOC LWCBR bit is not set (step 920), an abr_avail signal is asserted (step924) to indicate that a cell is available in the abr tx data FIFO 302.

Tx phy FSM 134

The tx phy FSM 134 reads the SOC longwords and cell data from the txdata FIFO 132 and transfers cell data to the PHY interface 80 fortransmission to the Utopia interface. The functions of the tx phy FSM134 are generally as follows:

transfer of AAL5, AAL5 EOP, MPEG EOP, Raw, BRM and FRM cells from the txdata FIFO 132 to the PHY interface 80;

creation of the cell header for AAL5, AAL5 EOP, MPEG EOP, BRM and FRMcells. Raw cells are transmitted unmodified except for the CONTROLLEDbit in the GFC field;

generation of 40 bytes of payload for BRM and FRM cells;

generation of CRC10 for RM cells, and for raw cells when the CRC_Ena bitis set;

generation of the 8-bit ABR_current_time and CBR_current_time pointers;

synchronization of transmission of cells to current time—i.e. cells arenot transmitted until current_time>=the Sched_time timestamp for thecell.

FIG. 29 is a block diagram of the tx data FIFO 132 and the tx phy FSM134 when GFC is enabled; i.e. the tx data FIFO 132 is segmented into acbr tx data FIFO 300 and an abr tx data FIFO 302. The cbr and abr txdata FIFOs 300 and 302 each contain up to 8 tx data FIFO entries 931.Each entry 931 includes the cell data and the tdf SOC LW 818 includingthe Sched_time timestamp field 822. The head entry 931 from each of thetx data FIFOs 300 and 302 is coupled to the tx phy FSM 134. Within thetx phy FSM 134 is a CBR_current_time counter 932 and an ABR_current_timecounter 934. The CBR_current_time counter 922 produces as output thecurrent location of the CBR_current_time pointer (cbr_curtime). Theoutput of the CBR_current_time counter is coupled to a comparator 936,as is the timestamp 822 from the head entry 931 of the cbr tx data FIFO300. When the comparator 936 detects that cbr_curtime is greater than orequal to the contents of the timestamp 822, a driver 938 is enabled inorder to pass the head entry 920 from the cbr tx data FIFO 300 to thePHY 80. Likewise, the ABR_current_time counter 934 produces as outputthe current location of the ABR_current_time pointer (abr_curtime). Theoutput of the ABR_current_time counter is coupled to a comparator 940,as is the timestamp 822 from the head entry 920 of the abr tx data FIFO302. When the comparator 940 detects that cbr_curtime is greater than orequal to the contents of the timestamp 822, a driver 942 is enabled inorder to pass the head entry 930 from the cbr tx data FIFO 300 to thePHY 80.

FIGS. 30a-30 d show a flow diagram of the functionality of the tx phyFSM 134. As shown in FIG. 30a, the tx phy FSM 134 first sets therd_entry_dec[1:0] vector to TX_NULL_CELL (step 950). Therd_entry_dec[1:0] vector is used by the fifo_remain counter to keeptrack of the number of entries remaining in the abr tx data FIFO 132, aspreviously described. The tx phy FSM 134 then checks a phy_FIFO_full bitfrom the PHY interface 80 (step 952). If the phy_FIFO_full bit isdeasserted, indicating that there is room in a phy synch FIFO (notshown) in the PHY interface 80 to accept data from the tx data FIFO 132,the tx phy FSM 134 then checks a cbr_avail bit (step 954) from the txdata FIFO 132 to determine whether any CBR cells are available in thecbr tx data FIFO 300 for transmission.

If the cbr_avail bit is asserted, the tx phy FSM 134 checks acbr_soc_valid bit (step 955). This bit indicates as to whether the SOClongword at the head of the cbr tx data FIFO 300 has been read. If thebit is deasserted, the tx phy FSM 134 reads the tdf SOC LW 818 in thecbr tx data FIFO 300 (step 956), and sets the cbr_soc_valid bit. TheSched_time timestamp field 822 in the tdf SOC LW 818 is then compared tocbr_curtime (step 958) via the comparator 936.

The Sched_time timestamp field 822 in the tdf SOC longword is a copy ofthe Sched_time field (358 or 388) originally written to the tx DMArequest FIFO 125 when the cell was scheduled for DMA. For the segmentedFIFO case described here, the Sched_time field was written with thevalue of cbr_sch_time at the time of DMA scheduling. The tx phy FSM 134now compares this timestamp to cbr_curtime (step 958). If cbr_curtime isgreater than or equal to the timestamp, a cbr cell will be transferredfrom the tx data FIFO 132 to the PHY interface 80. Cell transmissionsare thereby synchronized to occur at the rate intended when the cellswere scheduled in the CBR schedule table 176.

For example, consider a VC scheduled in the CBR schedule table 176 atlocations 2, 4, 6, and 8, such that transmission of these cells isintended to use 50% of the link bandwidth. As this VC is scheduled forDMA by the tx DMA scheduler 122, the successive entries will betimestamped (i.e. the Sched_time field 358 will be written) with thevalues 2, 4, 6, and 8. After DMA, these cells reside back-to-back in thecbr tx data FIFO 300. If the timestamp is ignored, the cells will betransferred to the PHY interface 80 in a back-to-back manner, therebyusing the full link bandwidth. Instead, the tx phy FSM 134 compares thetimestamp to cbr_curtime via comparator 926. When cbr_curtime=1, an idlecell is transmitted from the PHY interface 80 because the timestamp 792at the head of the cbr data FIFO is greater than cbr_curtime. Atcbr_curtime=2, the scheduled cell is transmitted; at cbr_curtime=3, anidle cell is transmitted, and so on. Thus, by comparing the timestamp792 to cbr_curtime, the tx phy FSM 134 ensures that the cells aretransmitted at the intended rate.

Referring back to FIG. 30a, if the tx phy FSM 134 finds that cbr_curtimeis greater than or equal to the timestamp 792 in the tdf SOC LW 818 atthe head of the cbr tx data FIFO 302 (step 958), it resets thecbr_soc_valid bit (step 960), and then proceeds to determine whether thecell to be transmitted is an AAL5, AAL5 EOP, MPEG EOP, or Raw cell. Ifthe cell is an AAL5 (or MPEG, treated here as AAL5) cell (FIG. 30b, step962), the tx phy FSM 134 generates the ATM cell header for the cell(step 964). Accordingly, the GFC bit in the cell header is set tocontrolled or reset to uncontrolled depending upon whether the cell ison a GFC controlled VC. The PT bit is set to 0 for non-EOP cells, andthe CLP bit is set to the value read from the SOC longword CLP field.The VPI and VCI fields are set according to a VPI/VCI mapping algorithmthat operates on the VC number. The cell header is written to the PHY(step 966), and the cell data is then transferred from the cbr tx dataFIFO 300 to the PHY (step 968). The rd_entry_dec [1:0] vector is thenset to the value tx_AAL5 cell (step 970).

If the cell is an AAL5 or MPEG EOP cell (step 972), it is handled in thesame manner as previously described except that the PT bit in thegenerated cell header is set to 1 (step 974).

If the cell is a raw cell (step 976), no cell header is generated, sincethe header for the raw cell was originally provided by the driver 24 andis included as part of the data present in the tx data FIFO 132. The GFCbit in the header is, however, set to controlled or reset touncontrolled depending upon whether the cell is on a GFC controlled VC(step 978). The cell data is then moved from cbr tx data FIFO 300 to thePHY (step 980). If the CRC/Ena bit was set in the SOC longword (step982), the tx phy FSM 134 generates a CRC10 for the cell (step 984) andthen writes it to the PHY (step 986). The rd_entry_dec [1:0] vector isthen set to the value tx_RAW_cell (step 988). After transmitting a cell,the tx phy FSM 134 resets the data_on_CBR_channel bit (step 990).

Referring back to FIG. 30a, If the tx phy FSM 134 finds that no validtdf SOC LW is present in the cbr tx data FIFO 300 (step 954), or ifcbr_curtime is less than the tdf SOC LW timestamp field 822 (step 958),the tx phy FSM 134 then determines whether an abr cell should betransferred from the abr tx data FIFO 302 to the PHY interface 80.Referring now to FIG. 30c, if GFC flow control is disabled or if GFCflow control is enabled and set_A is asserted (step 996), the tx phy FSM134 checks an abr_avail bit from the tx data FIFO 132 (step 998). Theabr_avail bit is asserted only when the tx data FIFO 132 is segmentedand there is an entry available in the abr tx data FIFO 302 portion ofthe tx data FIFO 132. If an entry is available, the tx phy FSM 134checks an abr_soc_valid bit (step 1000). This bit indicates as towhether the SOC longword at the head of the abr tx data FIFO 302 hasbeen read. If the bit is deasserted, will proceed to read the tdf SOClongword from the abr tx data FIFO 302 and set the abr_soc valid bit(step 1001).

If GFC flow control is enabled, but set_A is deasserted, no ABR/UBR cellis transmitted. In this case, cell transmissions from the abr tx dataFIFO 302 are inhibited until set_A becomes asserted. As previouslydescribed, the fifo_remain counter (FIG. 17) then controls DMAscheduling of abr traffic to ensure that cbr traffic is not blocked.

After reading the tdf SOC LW, the tx phy FSM 134 checks to see ifabr_curtime is greater than or equal to the Sched_time timestamp 822. Aswas previously described with reference to CBR cell transfers, ABR/UBRdata cells will be transmitted only if abr_curtime is greater than orequal to the timestamp 822. If so (step 1002), the tx phy FSM 134 resetsthe abr_soc_valid bit (step 1003) and proceeds to transmit an ABR/UBRcell. The tdf SOC LW is further decoded to determine whether the cell tobe transmitted is an AAL5, AAL5 EOP, MPEG EOP, Raw cell, or RM cell.

AAL5, AAL5 EOP, MPEG EOP, and Raw cells are handled as previouslydescribed for cbr cells (FIG. 30b). The abr tx data FIFO 302 may alsohold RM cells. If the cell to be transmitted is an RM cell (step 1006),the tx phy FSM 134 first generates the RM cell header (step 1008). TheGFC field is set to controlled or reset to uncontrolled depending uponwhether the cell is on a GFC controlled VC. The PT field is set to 6 H,indicating an RM type cell. The CLP bit is set to the value contained inthe SOC longword CLP field. The VPI and VCI fields are set according toa VPI/VCI mapping algorithm that operates on the VC number. The cellheader is then transferred from the tx data FIFO 132 to the PHY (step1010). The tx phy FSM 134 then generates the 40 byte payload for the RMcell (step 1012). The payload for an RM cell is known to be 40 bytes ofvalue 6 AH. Note that, rather than using abr tx data FIFO 302 space tohold the RM cell payload, the tx phy FSM 134 generates the payload asneeded. The payload is then transferred to the PHY (step 1014). Finally,the tx phy FSM 134 generates the CRC10 for the RM cell (step 1016) andtransfers it to the PHY (step 1018). The rd_entry_dec [1:0] vector isthen set to the value tx_RM_cell (step 1020).

The tx phy FSM also functions to update the current time counters 932and 934. Referring now to FIG. 30d, the tx phy FSM 134 awaits theassertion of a phy_cell_sent signal from the PHY interface 80 (step1022). The PHY interface 80 transmits CBR and ABR cells from the tx dataFIFO 132 to the Utopia bus. When no CBR or ABR cells are available fortransmission at a particular time (i.e. curtime has not yet reached thetimestamp of the cell at the head of the tx data FIFO 132 or the FIFO isempty), then an idle cell is sent by the PHY interface 80 to the Utopiabus. The phy_cell_sent signal is asserted when the PHY interface hastransmitted a CBR or ABR cell from the tx data FIFO 132 or, if no CBR orABR cells are available for transmission at this time, when an idle cellhas been transmitted.

Once the phy_cell_sent signal is asserted, the tx phy FSM 134 determineswhether to advance the cbr_current_time and abr_current_time counters932 and 934. First, the stopcnt_cbr signal is checked (step 1026).

Recall that the CBR_schedule_time pointer advances ahead of theCBR_current_time pointer (whose value is output from the cbr currenttime counter 932). Due to PCI bus 18 latency, the advancement of theCBR_schedule_time pointer may stop for some period of time because thetx DMA request FIFO 125 is full. The CBR_current_time pointer, however,continues to advance. When cbr_curtime has caught up with cbr_sch_time,the stopcnt_cbr bit is set by the tx rate scheduler 120 to preventcbr_curtime from passing cbr_sch_time. No CBR cells will be transmitteduntil stopcnt_cbr is cleared. Thus, if the stopcnt_cbr signal isasserted, cbr_curtime is not incremented. If the stopcnt_cbr signal isdeasserted, cbr_curtime is incremented (step 1028).

The tx phy FSM 134 now determines whether to increment the abr currenttime counter 934. checks the segmented_fifo signal to see if abr_curtimeshould be updated (step 1029). Accordingly, if the abr tx data FIFO 302is empty, or if there is an entry in the abr tx data FIFO 302 butabr_curtime is less than the timestamp for the entry (step 1030), thestopcnt_abr signal is checked (step 1032). As previously described forcbr traffic, the stopcnt_abr bit is set by the tx rate scheduler 120 toprevent abr_curtime from passing abr_sch_time. If the stopcnt_abr signalis deasserted, then the tx phy FSM 134 increments the abr current timecounter 934, thereby incrementing abr_curtime (step 1034). Otherwiseabr_curtime is not incremented.

Note that, due to the condition check at step 1030, when ABR cells arenot being transmitted because, for example, GFC set_A is deasserted,abr_curtime will be incremented only until abr_curtime reaches thetimestamp value 822 contained in the tdf SOC LW 818 of the next entry inthe abr tx data FIFO 302. Then, when abr flow is enabled, i.e. a GFCset_A bit is received, the next cell will be transmitted immediately.

Alternatively, abr_curtime could be incremented regardless of the nextentry timestamp, until abr_curtime reaches abr_sch_time. In this case,when the abr flow is enabled, all entries in the abr tx data FIFO 302with timestamps less than abr_curtime will be transmitted back-to-back(unless interrupted by cbr cell transmissions), at full link bandwidth.

Note that, when PCI bus 18 latencies become unusually large, the cbrand/or abr tx data FIFO 300, 302 may remain empty for some time whilethe cbr_current_time and abr_current_time counters 932 and 934 continueto advance. In this case, when cell data is finally available in the txdata FIFO 132, a number of cells may have timestamps less thancbr_curtime or abr_curtime. In this case, all cells with timestamps lessthan curtime will be transmitted back-to-back on the link. Celltransmission will therefore be out of synch with the schedule table rateintended. This will only occur for at worst 32 cells (the maximumallowed difference between abr_curtime and abr_sch_time). However, thismay advantageously prevent cells from being dropped from scheduling dueto back pressure.

When GFC is disabled, the tx data FIFO 132 is configured as a singleFIFO holding both CBR and ABR/UBR cells. In this case, only thecbr_current_time pointer need be used. Thus, when the segmented_fifosignal is deasserted, the timestamp values 822 in the tdf SOC LWs 818are derived from abr_sch_time (FIG. 22c at step 518) and compared tocbr_curtime. Stopcnt_cbr is set whenever cbr_sch_time=cbr_curtime orabr_sch_time_(—cbr_curtime.)

It should be noted that the previously described is a specific exampleof a mechanism for associating timestamps with entries in a schedulememory to facilitate the transfer of data from a transmit buffer memoryat a particular rate. Various alternative implementations are availableto achieve the same result. The current time counters 932 and 934 shownin FIG. 30 (932, 934), for example, are specific examples of currenttime circuitry used to represent points in time at which data is to betransmitted from a transmit buffer memory (herein the tx data FIFO 132).Alternative circuitry, such as linear feedback shift registers, may beemployed for the same purpose. Furthermore, timestamps can be associatedwith entries in a schedule memory in a variety of ways. Though thepreferred embodiment implements the timestamp as a copy of a scheduletime pointer associated with an entry in the schedule table 174 whichthen becomes part of the DMA request entry and is ultimately forwardedto the tx phy FSM 134, the position of the entry in the schedule tablecould alternatively be stored as a timestamp anywhere, as long as thecircuitry for transferring the data from the transmit buffer memory(herein the tx phy FSM) can associate the timestamp with the data in thetransmit buffer memory. Furthermore, the timestamp need not be relatedto the linear position of the entries in the schedule memory. Forexample, the schedule memory might be implemented as a contentaddressable memory (CAM) accessed by a timer or counter which preferablyleads in time the output of the current time circuitry. In this case,the output of the CAM is a VC or pointers to a list of VCs to bescheduled for DMA. A DMA request could then be generated which includesthe value of the timer or counter output used to access the CAM as thetimestamp associated with the entry.

Furthermore, the current time circuitry herein embodied is implementedas counters (932, 934) which are continually incremented at the linerate up to the maximum size of the schedule table 174. These countervalues are compared to timestamps generated from schedule time pointervalues which are also incremented up to the maximum size of the scheduletable 174. Yet another alternative embodiment could employ current timecircuitry and timestamps which are incremented relative to each other.For example, consider that cbr_curtime is initially ‘0’, andcbr_sch_time is incremented until a valid cbr entry is found in the CBRschedule table 176. Suppose a valid entry is found at location ‘4’ inthe CBR schedule table 176. After a data transfer for the entry isinitiated and performed, the timestamp 822 in the entry at the head ofthe tx data FIFO 132 is ‘4’. When cbr_curtime reaches 4, the cell istransferred to the PHY interface 80, cbr_curtime is reset, andcbr_sch_time is reset. The next valid entry exists at location ‘8’ inthe schedule table. Now cbr_sch_time is advanced four times to take onthe value ‘4’, while cbr_curtime counts from 0 at the line rate. Whencbr_curtime reaches 4, the cell is transmitted.

Tx Status Reports and the Tx Report Queue

As data is transferred via a DMA operation from tx slots in host memory,the SAR controller reports to the driver in the host system the tx slotswhich have been consumed. Such a reporting mechanism enables the driverto recover and re-use the physical memory that had been occupied bythose tx slots. As illustrated in FIG. 1, this reporting mechanism takesthe form of the tx report queue 36 (from FIG. 1) residing in hostmemory. The tx report queue 36 is a fixed-size structure located at afixed location, which can be specified by the driver through theTx_Report_Base CSR, and must be 64-Byte aligned. In the describedembodiment, the tx report queue contains 1K entries, and each entry is 4bytes wide. It can be appreciated that the size of the tx report queueis chosen to be equal to the total number of tx slot descriptorssupported by the SAR controller.

Now referring to FIG. 31, there is depicted the format of a tx reportqueue entry 2000. As shown, the tx report queue entry 2000 includes a VCfield 2002 and an own field 2004. Also included are two reserved fieldsindicated by reference numbers 2006 and 2008. The VC field 2002specifies the VC associated with the AAL5 packet or raw cell which wastransmitted.

The own field 2004 contains an own bit for each entry in the tx reportqueue 36 to indicate whether the entry is owned by the adapter or by thehost system. After reset, the polarity of each own bit is initially setto “1”, indicating that the entry is owned by the adapter. Thereafter,it toggles every time the SAR controller fills the tx report queue. Thisscheme allows the driver to determine ownership of a given tx reportqueue entry without requiring driver writes to the queue. After thedriver has initialized the tx report queue by writing the own bits inall the entries in the tx report queue to 1, it will never write thequeue. Similarly, the SAR controller never reads the queue.

When the tx DMA scheduler FSM is creating a DMA request for the lastbyte(s) of data in a tx slot, it determines if the tx slot is anend-of-packet (EOP) slot, or, for AAL5 packets, if the Tx_AAL5_SM bit inthe tx VC state is set. If either is true (i.e., the transit slot is anEOP transmit slot or the transmit slot contains a streaming mode AAL5packet), the SAR controller initiates DMA of a status report entry intothe tx report queue and typically generates an interrupt after the dataDMA request has been serviced. This DMA operation is referred to as a txstatus report.

When all the data in a tx slot has been transferred via DMA across thePCI bus from host memory to the SAR controller, it is said that the txslot has been consumed. The SAR controller reports the consumption of atx slot in host memory to the host system through the tx status report.In general, the SAR controller only reports consumption of tx slots forwhich the EOP bit is set in the transmit slot descriptor. For AAL5 PDUs,the EOP bit is only set for the tx slot containing the last byte ofpayload of the packet. For AAL5 packets in streaming mode, the drivercan choose to report and interrupt per tx slot on a per-VC basis whetheror not the EOP bit is set (via the Tx_AAL5_SM bit in the tx VC statetable), but this is not the normal mode of operation. Typically, onlythe consumption of the last slot of an AAL5 packet results in a txstatus report.

Unlike AAL5 cell data, each raw cell is contained in a single tx slot.Under normal operation, then, a status report is generated for every txslot containing a raw cell. To provide relief to the host system, theEOP bit in the EOP field of the tx slot descriptors (shown in FIG. 10)is manipulated to mitigate the frequency with which tx status reportsare generated for raw cells. More particularly, the driver may choose toset the EOP bit for every raw cell tx slot, or, choose to mitigate thefrequency with which raw cell status reports take place by setting theEOP bit every N raw cell tx slots, where N is chosen so as to maximizethe performance of the driver. Hereafter, N is referred to as the rawcell status report mitigation number. It will be appreciated that, inalternative system implementations, a tx slot descriptor field otherthan an EOP field could be defined to indicate whether or not a raw celltx status report should be generated.

Referring back to FIG. 31, the driver uses the VC field 2002 in the txreport queue entry 1000 along with the FIFO order of packets within theidentified VC to determine which packets have completed transmission.For example, the driver could maintain a per-VC count of packets whichhave been queued for transmission but have not yet been transmitted.

In FIG. 32, there is shown a flow diagram illustrating a method of txstatus reports frequency mitigation for raw cells 2010. In thisembodiment, the host system selects a raw cell status report mitigationvalue N 2012, where N indicates the number of raw cell tx slots thatmust be consumed before a tx status report is generated. As part of step2012, the host system may initialize a count for counting a numbercorresponding to N. For each tx slot the driver prepares to post to theadapter, the following steps are performed. First, the driver determinesif the tx slot to be posted corresponds to (i.e., contains) a raw cell2013. If the driver is posting a tx slot for a raw cell, it decideswhether or not a tx status report should be generated. This decisionmaking step is indicated by 2014. It can be appreciated that thedecision can be performed by any host system controlled decision makingmechanism, whereby the posting of an Nth raw cell tx slot is detected.In this embodiment, the driver maintains a count as described above tokeep track of the number of raw cell tx slots posted. The count ismodified by one at step 2015. If the count is a downward counting count,initialized to the raw cell status report mitigation value N (or N plusas an offset value), it is decremented by one 2015. If the count is anupward counting count, initialized to zero (or some offset value) andcounting up to the raw cell status report mitigation value N (orN+offset value), it is incremented by one. If the count “expires”, i.e.,counts the Nth raw cell tx slots to be posted 2016, the driver knowsthat the raw cell tx slot to be posted for transmission is the Nth suchslot. The driver resets the count 2017 and, in response to the step ofdeciding, writes the tx slot descriptor associated with the tx slot,setting the EOP field in the associated tx slot descriptor to one 2018.If the count has not expired at step 2017, the driver writes the EOPfield with a zero 2019. It can also be appreciated that the host systemor driver could perform the decision making step 2014 in an alternativefashion, e.g., on a raw tx slot by raw tx slot basis without theassistance of a count or even a selection of N, in which case the methodwould commence at either of steps 2013 or 2014.

In response to the posting of the tx slot, a data transfer request iscreated for each data portion in the tx slot to be copied from the hostsystem in a separate data transfer operation 2020. In this embodiment,the data transfer request is a DMA request and the data transferoperation a DMA operation as previously described. If the data portionis the last in the tx slot 2021 and the tx slot is an EOP slot 2022(i.e., a tx slot having an associated tx slot descriptor in which theEOP bit in the EOP field has been set), the DMA request is serviced atstep 2023. Because the tx slot contains a raw cell, the servicing of theDMA request will result in the DMA of data from the tx slot to theadapter. Lastly, a tx status report is generated and sent to the hostsystem 2024. In the preferred embodiment, the tx status report DMA is aninterrupt event. The tx data DMA FSM therefore indicates to theinterrupt block that an interrupt event has occurred. If the dataportion is not the last in the tx slot, the DMA request is serviced inthe form of a DMA operation 2026 and the method returns to step 2018. Ifthe tx slot is not an EOP slot at step 2021, the DMA request is serviced2027.

FIG. 33 illustrates a method of generating tx status reports when the txslot to be posted at step 2014 is not a tx slot corresponding to a rawcell. Referring now to FIG. 33, if the host system is posting a tx slotcontaining the last byte in a packet 2028, it writes the associated txslot descriptor, setting the EOP bit as indicated by step 2029. Itshould be noted that this EOP bit is set for tx slots corresponding toidle slots at the option of the host system. Otherwise, the EOP bit inthe EOP field is zero according to step 2030. In response to the postingof the tx slot, the tx DMA scheduler creates a DMA request correspondingto a portion of data to be DMA'd from the transmit slot in host memory2031. If the data portion is the last in the transmit slot 2032 and thetx slot is determined to be an EOP slot 2033, the DMA request isserviced by first determining if the tx slot corresponds to an idle slot2034 and then initiating the DMA transfer of data from the host memoryto the adapter 2035 if the tx slot is not an idle slot. The tx data DMAFSM then DMAs a status report entry into the tx report queue in hostmemory 2036. Although not shown, there is an indication to the interruptblock that an interrupt event has occurred.

Still referring to FIG. 33, if the data portion is not the last in thetx slot at step 2032, no status report is sent. The DMA request isserviced by determining if the tx slot is an idle slot 2037 and DMA'ingdata if the tx slot is not an idle slot 2038. The procedure returns tostep 2031 for the next data portion. If the tx slot is not an EOP slotat step 2033, step 2039 determines whether or not tx slot storesstreaming mode packet data (referred to as a SM tx slot). If it does,and the slot is an idle tx slot 2040, no data is transferred 2041. Ifthe slot is not an idle tx slot, the DMA request is serviced at step2035 and a tx status report is generated at step 2036 as previouslydescribed. If the slot is not an SM tx slot at step 2039, the DMArequest is serviced by determining if the tx slot is an idle tx slot2042 and a data DMA operation is performed when the tx slot is not anidle slot 2043. If the tx slot is an idle slot, no data is copied fromthe tx slot in host memory 2041. As noted above, the host system shouldset the EOP bit for idle slots only if it desires to be informed of theconsumption of the slot. Although no data is DMA'd from idle slots, itmay still be useful for the driver to learn when an idle slot has beenconsumed (i.e., processed by the SAR controller). Idle slots use up txslot descriptors in the same way that other slots do, and the number ofoutstanding tx slot descriptors is limited to the size of the tx freeslot list.

As indicated earlier, the SAR controller usually signals an interruptevent and generates an interrupt request following the occurrence of atx status report. The frequency with which the interrupt request to thehost system occurs may also be mitigated through the use of an interruptholdoff mechanism. A more detailed description of the interrupt holdoffmechanism and the interrupt function in general follows the descriptionof the receive operation below.

Receive Operation

In order to receive data or units of data (e.g., PDUs, packets) intendedfor receipt by the host system, the driver must allocate physicallycontiguous areas of host memory into which the data should be DMA'd bythe SAR controller. These blocks of physically contiguous host memorywere shown in FIG. 1 as the rx slots 32. A single AAL5 PDU may be DMA'dinto a single rx slot, or may span multiple rx slots. Each received rawcell is contained in a single rx slot.

The rx slots 32 include three types: small, big and raw slots. Smallslots are intended to receive AAL5 PDUs on VCs on which the maximum PDUsize is expected to be small. All small slots must be the same size, andthe size is programmable through SAR_Cntrl2 in CSRs to be in the range64B-2KB. Big slots are those rx slots intended to receive AAL5 PDUs onVCs on which the maximum PDU size is expected to be larger than will fitin small slots. All big slots must be the same size. The size isprogrammable through the SAR_Cntrl2 CSR to be 1K, 2K, 4K, 8K, 10K, or16K bytes. Raw slots are those rx slots intended to receive 52-Byte rawcell data and accompanying status information per cell. All raw cell rxslots must therefore be 56-bytes in length. They may be longer, but onlythe first 56 bytes of each rx slot will be used. All rx slots must belongword-aligned in the host memory. The SAR controller completely fillsrx slots, with the exception of raw cell rx slots over 56 bytes inlength, and EOP AAL5 rx slots (since the last portion of an AAL5 PDU maynot exactly fill the last rx slot used by the PDU).

When the driver opens a VC for reception of data, it assigns a slot typeto that VC. The VC then receives data only into the assigned slot type.One notable exception is the F5 OAM cell, as this type of cell is placedin a raw cell rx slot regardless of the slot type assigned to the VCwith which it is associated.

FIG. 34 illustrates an example of an AAL5 packet which has beentransferred via a DMA operation into three rx slots in host memory. Therx slots are big slots, each of which is 2KB in length. The packet isexactly 4128 bytes in length, including the AAL5 pad, control, lengthand CRC fields.

Once the driver has allocated rx slots in the host memory to receivedata from the SAR controller, or, alternatively, when the driver wishesto reuse rx slots from which it has extracted received data, it providesto the SAR controller the addresses of the allocated rx slots. For eachrx slot 32 allocated for the reception of data, the driver 24 writescontrol information to an address space in the SAR controller 62. Inthis embodiment, the control information is two longwords; thus, thewrite must be 2-LW (quadword) aligned. Referring back to the CSRs shownin Table 1, the address space is indicated in the table as “rx pendingslots” address space. When the driver 24 writes two consecutive LWs ofcontrol information describing a single rx slot to this address space,the operation is referred to as posting an rx slot. The two LW writesneed not necessarily occur in a single PCI burst. The SAR controller isdesigned to handle an arbitrarily long delay between the write of thefirst and the second LWs corresponding to the posting of a single rxslot. In this embodiment, the rx pending slots address space is 16-LWdeep to allow for the posting of up to eight rx slots in a single 16-LWPCI burst.

FIG. 35 illustrates the major components of the reassembly engine 90(from FIG. 4). An rx control memory 2048, preferably implemented as andalternatively referred to as an rx pending slot FIFO 2048, having rxpending slot entries 2050, is connected to the PCI bus interface (fromFIG. 4), and an rx PHY synch FIFO 2052, having rx PHY synch FIFO entries2054, is connected to the PHY interface (also from FIG. 4). The rx PHYsynch FIFO 2052 provides byte-wide buffering to cell data received fromthe PHY interface. Coupled to both the rx pending slot FIFO 2048 and therx PHY synch FIFO 2052 is an rx cell manager 2055, which includes an rxfree slot manager 2056 for performing pending rx slot processing and rxfree slot buffer memory management, as well as an rx cell processor forperforming ATM and AAL level processing on received rx cells in the rxPHY synch FIFO 2052.

Further illustrated is the local memory 76 (external to the reassemblyengine 90 in this embodiment and thus indicated by dashed lines), sincevarious data structures within the control memory are utilized duringthe reassembly operation. As can be seen in the figure, the rx cellmanager 2055 is connected to the local memory 76, thus enabling the rxcell manager 2055 to access the data structures in the local memory 76.To simplify the figure, only those data structures pertinent to thereassembly process, and more particularly, to an understanding of thepresent invention, are shown. Those data structures include the rx freeslot FIFOS 139, more specifically including the rx “small” free slotFIFO 141, the rx “big” free slot FIFO 140 and the “raw” free slot FIFO142, each of which includes free slot FIFO entries 2058 for storing 2 LWaddresses (which will be described later) of allocated rx slots. Alsoshown are the rx small slot_tags table 170 for storing as entries smallrx slot tags 2060 assigned to small rx slots, the rx big slot_tags table168 for storing as entries big rx slot tags 2062 assigned to big rxslots and an rx raw slot_tags table 172 for storing as entries raw rxslot tags 2064 assigned to raw rx slots. Thus, each rx slot tag isassociated with a single entry in a corresponding one of the rx freeslot FIFOs.

Further included in the illustrated data structures of the local memoryare the rx slot_tag VC state table 144 and the rx VC state table 150.The rx slot_tag VC state table 144 includes an rx slot_tag VC stateentry 2066 for holding the rx slot tag of the rx slot currently in useby the VC with which the entry is associated. The function of the rxslot tags will be described in some detail later. The rx VC state table150 includes an rx VC state table entry 2070 for storing informationassociated with each VC over which incoming cell data is carried. Thesedata structures retain the same reference numbers used in FIG. 7.

Returning to a consideration of the reassembly engine components shownin FIG. 35, the rx cell manager 2055 is further connected to and feedsan rx buffer memory 2072, implemented as an rx data FIFO, having rx dataFIFO entries 2074, as well as CSRs (CSRs 86 from FIG. 4). The rx dataFIFO 2072 feeds an rx data synch FIFO 2076, having rx data synch FIFOentries 2078, under the control of an rx data FIFO read controller 2080.An rx DMA engine 2082 is connected to the rx data synch FIFO 2076, thePCI bus interface (PCI bus interface 78 from FIG. 4), a temporarystorage space indicated as rx raw report holdoff registers 2084 and araw report counting device implemented as a raw_rpt_hldoff (raw reportholdoff) counter/timer 2086. It is also connected to and interacts withthe interrupt block (interrupt block 96 from FIG. 4). Although thepreferred embodiment employs an rx DMA engine, data synch FIFO and dataFIFO read controller for controlling data transfer, and the DMA enginefor performing the transfer of data, other arrangements may be employedto perform these control and data transfer functions. Alternativedevice(s) or combinations of varying degree of integration may be usedto move the data from the rx data FIFO to the host memory. The rx DMAengine 2082, rx cell manager 2055 and rx data FIFO read controller 2080are control units which may be implemented via any number of known logicdesign methods, such as hard-wired, programmable logic based ormicroprogrammed control. Inasmuch as the implementation details are amatter of design choice and need not limit the scope of the presentinvention, the treatment of these control units will remain at thehigher functional level. The operation of the various reassembly enginecomponents depicted in FIG. 35 during the reassembly process is asfollows.

Still referring to FIG. 35, the data written by the driver to the rxpending slots address space is placed in the rx pending slot FIFO 2048by the PCI bus interface (from FIG. 4) operating in PCI slave mode. Eachtime a set of 2-LW writes occurs to the rx pending slots address space,the PCI bus interface places a pending slot FIFO entry 2050 on the rxpending slot FIFO 2048. This pending slot FIFO entry 2050 is alsoreferred to as an rx slot descriptor 2050. In the described embodiment,the rx pending slot FIFO is capable of storing eight (2 LW) entries.

It is important to note that each host-PCI “write” to the pending slotFIFO operates according to the technique described with reference toFIGS. 8A-B and 9. The consecutive CSR burst write technique as discussedin the preceding transmit/segmentation section is as applicable to thereceive operation as it is to the transmit operation. In fact, thetechnique can be applied to any system performing burst writes to asingle device location as discussed earlier.

Illustrated in FIG. 36 is the format of the rx pending slot FIFO entry2050, alternatively referred to as an rx slot descriptor 2050 or controlinformation 2050. The first LW (LWO) 2087 is organized as a VC field2088, a slot type (slot_type) field 2090, a reserved field 2091 and aslot tag (slot_tag) field 2092. The VC field 2088 indicates the VCassociated with the rx slot being posted. In this example, the VC fieldstores a 12-bit VC. It should be noted that rx slots are not associatedwith particular VCs when they are queued by the driver. The 12-bit VCfield 2088 in the rx pending slot FIFO entry 2050 is used solely for thepurposes of handling rx congestion, as later described. The slot typefield 2090 indicates the type of rx slot being posted. Here, the slottype field 2090 is a two bit field and is decoded as follows:

00—Small

01—Big

10—Raw

11—Reserved

The slot_tag field 2092 uniquely identifies the rx slot being posted. Itis used by the driver to obtain the virtual address of an rx slot oncedata has been placed in the slot by the SAR controller. When the driverallocates an rx slot for receiving data from the SAR controller, itindicates to the SAR controller the physical address of the rx slot.Because the two types of AAL5 slots (big and small) are shared amongVCs, and because both types of slots may hold several cells of data, therx slots may be consumed (filled with data) in an order different fromthe order in which they were posted. Consequently, the SAR controllermust report the consumption of every AAL5 receive slot in a manner whichunambiguously identifies the slot being reported. Although the physicaladdress of a slot uniquely identifies the rx slot, it is cumbersome inmany operating systems to translate the physical address to the virtualaddress needed by the driver. Therefore, the SAR controller uses slottags to simplify the driver's task in processing rx slots.

The operation of the driver with respect to slot tag usage is asfollows. First, the driver assigns a unique slot tag to each rx slotwhich has been allocated for use by the SAR controller. Once the slottag has been assigned, the driver stores the slot tag in associationwith the virtual address of the rx slot to which it has been assigned.In the embodiment shown in FIG. 1, the slot tag and virtual address pairare stored as an entry in the lookup table 40. Next, the driver providesthe SAR controller with the slot tag and the physical address of the rxslot. When the SAR controller has placed data to be processed by thedriver in an rx slot, the SAR controller reports to the host system thatthe rx slot is full by returning the slot tag associated with the rxslot to the driver. The driver then uses the returned slot tag to obtainthe associated virtual address of the rx slot to be processed from thelookup table.

Slot tags are unnecessary for raw rx slots, since the raw slot type canhold only one cell and is consumed in the order in which it is providedto the SAR controller. For simplicity, however, the SAR controllerutilizes slot tags for all supported slot types.

Returning again to FIG. 36, a second LW (LW1) 2094 of the rx pendingslot FIFO entry 2050 includes a base address field 2096, which iswritten by the driver with the physical address of the rx slot beingposted. This physical address, 32-bits wide in the describedimplementation, is the base or starting address of the rx slot. Becausethe rx slots must be longword-aligned, the least-significant 2 bits ofthis field are always zero.

As the driver posts rx slots for transmission, entries are placed in therx pending slot FIFO until it is full, at which point the host system isdisconnected from the PCI bus. Whenever a burst to the rx pending slotFIFO from the host system begins, the SAR controller determines how manycompletely empty spaces (spaces for a complete 2LW entry) are availablein the rx pending slot FIFO and allows only that number of entries to bewritten by the driver before disconnecting the host system.

With reference to FIG. 35, the rx free slot manager 2056 takes entriesoff of the rx pending slot FIFO 2048 and copies the address field 2096in each entry into one of the rx free slot FIFO entries 2058 (in thelocal memory 76) according to the slot type specified in the slot typefield 2090 in the rx pending slot FIFO entry 2050. In the describedembodiment, each of the rx free slot FIFOs has a different one of theslots types (small, big, or large in this embodiment) associatedtherewith. Thus, each of the rx free slot FIFOs holds addresses for theassociated slot type and can hold up to 1K entries in 1K-VC mode.Pointers to the head and tail of each of the rx free slot FIFOs are keptin CSRs 86 (from FIG. 4). Entries are taken from the head of and writtento the tail of the rx free slot FIFOs in the described embodiment. Sincethe head and tail pointers of the rx free slot FIFOs are kept in the SARcontroller itself, they are initialized by the SAR controller atpower-up or reset.

It is appropriate at this point to consider briefly, with reference toFIG. 37, the layout of the rx VC state table entry 2070. A CRC10_Enfield 2098 is used to selectively enable or disable CRC10 checking. Adrop flag 2100 indicates that cells on the VC should be dropped. An openfield 2102 indicates that the VC has been opened by the driver. AVC_congestion flag 2104 (also referred to as congestion flag 2104)indicates that the VC to which the entry corresponds is congested. Acell loss flag 2106 indicates c ell loss has occurred on the VC andshould be reported to the host system. An rx_AAL5_SM field 2108 enablesor disables rx AAL5 packet streaming mode. When this field is set and rxAAL5 streaming mode thereby enabled, AAL5 status reports and interruptscan occur on a “per slot” basis. A slot_type field 2110 selects the typeof rx slot (i.e., big or small for AAL5 PDUs, or raw for raw cells) tobe used for data received on the VC. A slots_consumed field 2112indicates the number of slots consumed by the VC and not yet returned bythe host system for reuse. An AAL5_length field 2114 is used to countthe number of received bytes in AAL5 pDUs. An AAL5_slot_address field2116 stores the base address of the rx slot currently being used forAAL5 data on the VC. An rx_AAL5_CRC field 2118 stores a partial CRC-32for received AAL5 PDUs. A slot_pointer 2120 is a write pointer intocurrent rx slot. An OR_CI field 2122 i s used to select the logical ORof EFCI bits (from cell header PT<1>) of received cells in an AAL5packet. An OR_CLP field 2124 is used to select the logical OR of CLPbits of received cells in an AAL5 packet. As the fields corresponding toreference numbers 2126 through 2132 do not directly relate to theinvention, a description of these fields is not provided.

Whenever a new rx slot is needed for reception of data, the rx VC statetable entry 2070 serves to associate slot type with the VC of theincoming cell. The slot_type field 2110 in the rx VC state table entry2070 for the incoming cell indicates the slot type and thus the correctrx free slot FIFO to be selected for rx slot allocation purposes. The rxcell manager 2055 is able to index into the rx VC state table to accessthe appropriate entry by reading VCI and VPI (reference numbers 52 and50 in FIG. 2) in the cell header (header 44 in FIG. 2) of received cellsit removes from the rx PHY synch FIFO 2052. It should be noted that theVPI_VCI_Mapping field in the SAR_Cntr1 CSR shown in Table 1 providesVCI/VPI to VC mapping. Once the appropriate slot type is obtained, anentry corresponding to an rx slot is popped off of the correct rx freeslot FIFO and the address contained therein written to the slot_addressfield 2116 in the rx VC state table. The reception of an incoming cellwill cause a new rx slot to be taken from one of the rx free slot FIFOsby the rx free slot manager whenever that rx cell starts a new packet orwhen the previous slot allocated to the cell's VC has no more spaceavailable for storing rx cell data. Every raw or F5 OAM cell isconsidered a single-cell packet.

Once an rx slot corresponding to an rx free slot FIFO entry has beenfilled with receive data, the slot tag which uniquely identifies theconsumed rx slot is reported to the driver (with the exception of rawcell slots, which may not all be reported) as previously mentioned. Foreach slot type, the driver must keep a count of how many TOTAL slots(across all VCs) have been posted but not yet reported, and ensure thatthis number never exceeds the maximum size of the free slot FIFOs (1Kentries in 1K-VC mode).

If any of the rx free slot FIFOs 139 has been completely filled withdata, the SAR controller stops processing posted rx slots. If the driverattempts to post one or more additional rx slots once both the free slotFIFO and the rx pending slot FIFO become full, the access is retrieduntil the free slot FIFO is no longer full.

Referring once again to FIG. 35, the rx data FIFO 2072 providesbuffering for incoming rx cells after processing by the rx cellprocessor. At STS-3c/STM-1 line rates, this equates to approximately 200μs worth of PCI latency buffering. As shown, the rx data FIFO 2072 isimplemented as two banks of 32-bit wide SRAM to emulate a dual-portSRAM, thus enabling the rx data FIFO read controller 2080 to read fromit at a full PCI burst rate. In this embodiment, each incoming cell inthe rx data FIFO is stored as either a 60-byte quantity if the cell is araw cell, or as a 56 or 64 byte quantity if the cell is an AAL5 cell.The rx cell processor 2057 reads the incoming cell data from the rx PHYsynch FIFO 2052, removes the cell headers, calculates CRCs and updatesthe rx_AAL5_CRC field 2118 in the rx VC state table entry 2070 for thecell data as necessary and writes the cell data to the rx data FIFOalong with associated control information obtained from the VC stateentry and an rx free slot buffer memory allocated by the rx free slotmanager.

FIG. 38 illustrates the appearance of the rx data FIFO 2072 when itcontains exactly three full cells, the first and last of which are rxAAL5 cells 2136, and the middle of which is an rx raw cell 2138. In theexample shown, the first AAL5 cell fits in a single slot, while thesecond straddles 2 slots, with 44 bytes in the first slot and 4 bytes inthe second slot. A single AAL5 cell is stored along with associatedcontrol information in the form of a 2-LW AAL5 cell start-of-DMA (SOD)control entry 2140 for each DMA burst which will be required to storethe cell. Thus, if a cell fits in a single rx slot, it will be stored asa 2-LW SOD control entry followed by 48 bytes of data, the 48-byte AAL5cell data indicated by reference number 2142. If a cell straddles two rxslots, it will be stored as a first SOD entry followed by the bytes tobe placed in the first rx slot, then a second SOD longword followed bythe bytes to be placed in the second rx slot (64 bytes in total). Thereare thus 2 SOD entries associated with the second AAL5 cell. When rxslots which are to receive AAL5 data must be at least 64 bytes inlength, a cell can occupy at most 2 rx slots.

The raw rx cell 2138 is stored as a raw cell SOD control entry 2144,followed by 52 bytes of raw cell data 2146 and a rx raw cell statuslongword 2148. The raw cell data 2146 and the raw cell status longword2148 are DMA'd into the rx slot indicated by the raw cell SOD entry2144.

FIG. 39A illustrates the rx AAL5 cell SOD entry 2140. As shown, the rxAAL5 cell SOD entry comprises a DMA size (DMA_size) field 2150, a rawfield 2152, a report field 2154, and a DMA base address(DMA_base_address) field 2156. The entry also includes two reservedfields, indicated by reference numbers 2158 and 2160. The report field2154 is used to indicate whether the SOD entry is a data DMA request (0)or an AAL5 Status Report DMA request (1). The raw field 2152 indicateswhether a data DMA request is an AAL5 request (0) or a raw request (1).The DMA_Base_Address field 2156 indicates the starting address (inlongwords) to which data should be transferred for data DMA requests.The address in the DMA_Base_Address field is derived by the rx cellprocessor 2057 by adding the address of the current rx slot being usedfor the VC on which the data has been received to the slot_pointer 2120kept in the rx VC state table entry 2070. The number of longwords to betransferred via DMA for AAL5 data requests is indicated by the DMA_sizefield 2150, implemented as a 4-bit field. The size may be specified inlongwords as all rx slots are longword aligned and a multiple of 1 LW insize.

FIG. 39B illustrates the rx raw cell SOD longword 2144. Like the rx AAL5cell SOD entry 2140 shown in FIG. 39A, the rx data raw cell SOD entry2144 includes DMA_base_address, raw and report fields, each of which isindicated by the same reference number as the equivalently named fieldin FIG. 39A.

Shown in FIG. 39C is a third type of entry which may appear in the rxdata FIFO 2072. An AAL5 status report SOD entry 2160 is a request to therx DMA engine to report the consumption of an rx slot to the hostsystem. No data follows an AAL5 status report SOD entry. In common withthe other two types of entries is the report field 2154. Additionally,the rx AAL5 status report SOD entry 2160 includes an interrupt (Int)field 2162, which indicates when set that an interrupt should begenerated immediately following a status report. This bit is set for EOPentries and for every entry associated with an AAL5 streaming mode VC. Aslot tag (slot_tag) field 2164 provides the slot tag of the AAL5 rx slot(small or big) which has been filled with receive data and is beingreported to the host system. A bad field 2166 indicates if the packetbeing reported should be processed normally by the driver (0) or if anerror condition was experienced while receiving the packet which shouldresult in the discarding of the packet (1). When this bit is set, astatus field 2168 indicates the reason why the packet should bediscarded. When the bit is cleared, the status field 2168 givesinformation about the VC on which the packet was received. Table 3 belowprovides the bad and status bit decoding in the rx AAL5 status reportSOD entry.

TABLE 3 BAD STATUS MEANING 0 XXX Status<0> = Slot congestion experiencedStatus<1> = Packet loss experienced Status<2> = Reserved 1 000 CRC-32error, discard packet 1 001 Length error, discard packet 1 010 Abortedpacket, discard packet 1 011 Slot congestion cell loss, discard packet 1100 Other cell loss, discard packet (Rx data FIFO overflow or Rx freeslot exhaustion) 1 101 Reassembly timer timeout, discard packet 1 110Packet too long error, discard packet 1 111 Reserved

The VC of the data which has been placed in an AAL5 rx slot is indicatedby a VC field 2170. The driver uses this 12-bit field to reconstructreceived AAL5 packets which are spread out among multiple rx slots. Asize field 2172 indicates the number of valid longwords in the reportedrx slot. This 12-bit field will usually be equal to the size (inlongwords) of the rx slot being reported, except for end-of-packet rxslots (rx slots containing the last byte of an AAL5 packet), which willprobably not be completely filled. Also, the value 0×000 is used torepresent exactly 16KB of valid data. The driver reads this field todetermine packet boundaries in end-of-packet rx slots. This field isvalid only if the bad bit is not set.

An EOP field 2174 indicates if the slot being reported is anend-of-packet rx slot. It is used in normal operation by the driver tofind AAL5 packet boundaries.

An EFCI field 2176 is either the logical OR of all the EFCI bits in thecells which make up a received AAL5 packet, or the EFCI bit in the lastcell received in the packet. The selection of which of the two modes isto be used is made through the OR_CI field 2122 in the rx VC state table150. It is of significance only for end-of-packet rx slots.

A CLP field 2178 is the logical OR of all the CLP bits received in thecells which make up a received AAL5 packet when enabled by the settingof the OR_CLP field 2124 in the rx VC state table. Like the EFCI field,it is of significance only for end-of packet rx slots.

A start of packet (SOP) field 2180 indicates if the rx slot beingreported contains the first byte of an AAL5 packet. It is used by thedriver to detect error conditions which may not have been reported dueto lack of rx slots (i.e., receive congestion). Also included is areserved field 2181.

As mentioned above, each 52-byte raw cell is DMA'd into host memory withthe accompanying raw cell status longword 2148 (from FIG. 38). Thedriver uses the raw cell status longword 2148 to obtain informationabout the raw cell and about the VC on which the raw cell has beenreceived.

FIG. 40 depicts the format of the raw cell status longword 2148. Asillustrated, it includes a slot tag (slot_tag) field 2182, a cell loss(cell_loss) field 2184, a slot congestion (slot_congest) field 2186, aCRC10 error (CRC10_err) field 2188 and a VC field 2190. A reserved fieldis indicated by 2192. A description of each of these fields follows.

The VC field 2190 identifies the mapped VC of the raw cell. TheCRC10_Err field 2188 indicates, when set, that a CRC10 check was done onthe raw cell and an error was detected. The driver should thereforediscard the cell. The Slot_cong field 2186 indicates, when set, that theVC of the raw cell has experienced slot congestion. Cell loss may or maynot have occurred as a result of the congestion. The Cell_loss field2184 is set to indicate that the VC of the raw cell has experienced cellloss (of 1 or more cells). This cell loss may have occurred for one ormore of the following reasons: rx free slot exhaustion, rx data FIFOoverflow or slot congestion on the VC (for data cells in non-FlowMastermode). The slot_tag field 2182 contains the slot tag of the rx slot intowhich the raw cell has been DMA'd.

Referring a gain to FIG. 35, the rx data FIFO read controller 2080determines if a complete request is available in the rx data FIFO 2072.When the rx data read cont roller 2080 detects that a new entry has beenplaced in the rx data FIFO 2072, it moves the SOD longwords and datafrom the rx data FIFO 2072 to the rx data synch FIFO 2076, and informsthe rx DMA engine 2082 that a new rx DMA operation should take place.Each rx data FIFO entry 2074 in the rx data FIFO 2072 may correspond toa single raw cell DMA (56 bytes), an AAL5 data DMA (1-48 bytes), or anAAL5 status report (8 bytes) as previously described. Thus, the rx dataFIFO read controller 2080 must immedi ately begin moving any DMA datafor the burst from the rx data FIFO 2072 to the rx data synch FIFO 2076as soon as the SOD entry for the burst has been moved.

Although not shown, the rx data FIFO read controller 2080 can detectthat data is available in the rx data FIFO 2072 by polling a counterwhich counts the number of complete requests stored in the rx data FIFO.If the counter is non-zero, the rx data FIFO read controller knows thata rx DMA request is present and that data may be moved to the rx datasynch FIFO 2076 if the rx data synch FIFO 2076 is available.

The rx data synch FIFO 2076 provides buffering across the PCI bus andcore clock domains for receive data. Preferably, it is 16 LW deep, thusproviding adequate buffering for the maximum receive DMA burst of 14-LW,in addition to 1 LW of control information for the burst (for rawcells), or for a 12-LW burst and 2 LW of control information for theburst (for AAL5 data).

As soon as a first longword of an SOD entry is moved to fill one of therx data synch FIFO entries 2078, the rx data FIFO read controller 2080signals to the rx DMA engine 2082 that it may begin to process the rxrequest. Since this indication is given early (i.e., before all of thedata to be DMA'ed has been placed in the rx data synch FIFO), the rxdata FIFO read controller 2080 needs to ensure that data is moved intothe rx data synch FIFO 2076 at the rate of 1 longword per core clockcycle once the indication is given. This will ensure that the rx datasynch FIFO 2076 will be not underrun by the rx DMA engine 2082 as datais read from the rx data synch FIFO and DMA'ed to host memory.

Rx Status Reports and the Rx Report Queue

As data is written to the rx slots in host memory, the SAR controllerreports to the driver the rx slots which have been consumed (i.e.,filled with data) so that the driver may read the data from and repostthose rx slots to the appropriate free slot FIFO. Once the freed rxslots are returned to the appropriate free slot FIFO, they are availablefor reuse by the SAR controller during PDU reassembly.

Returning briefly to FIG. 1, the reporting mechanism used to report fullrx slots is provided by the rx report queue 38 in the reporting datastructures 34 of host memory 22. The rx report queue 38 is implementedas fixed-size structure located at a fixed location in host memory. Itconsists of 24KB of contiguous physical host memory, and its location isspecified by the driver through the Rx_Report_Base CSR, but it must be64-Byte aligned. It contains 3K entries, and each entry is 2 longwordswide. It can be appreciated that the size of the rx report queue 38 ischosen to be equal to the total number of receive slots supported by theSAR controller across all three of the free slot FIFOs. If the SARcontroller was to support a greater number of VCs, the total number ofrx slots supported would be likely to increase. Consequently, the sizeof the rx report queue would have to increase as well.

The two types of entries are illustrated in FIGS. 41A and 41B. As shownin FIG. 41A, an rx AAL5 report queue entry 2194 comprises the followingfields: a slot_tag field 2196, a raw field 2198, an own field 2200, anEOP field 2202, an SOP field 2204, a bad field 2206, a status field2208, a CLP field 2210, an EFCI field 2212, a size field 2214 and a VCfield 2216. A reserved field is indicated by 2218. In the sample formatshown, the entry is organized as two words, word0 2220 and word1 2222.Word0 includes the slot_tag, raw and own fields, with 16-bits beingreserved. The remaining field s belong to word2.

FIG. 41B depicts the format of an rx raw cell report queue entry 2224.When the report queue entry is utilized for an rx raw cell report, onlyword0 contains useful information. Like the rx AAL5 report queue entry,the rx raw cell report queue entry 2224 also includes the slot_tagfield, raw field, an own field and a 16-bit reserved field 2226 inword0. The reference numbers are the same as the equivalently namedfields in the rx AAL5 report queue entry. Word is entirely reserved asindicated by 2228.

In reference to both FIGS. 41A and 41B, a description of the illustratedfields follows. The Raw field indicates if the status report is for araw cell slot (1), or for a slot containing AAL5 data (0). With respectto the rx AAL5 report queue entry, the raw field 2198 is copied from theraw field 2152 of the rx AAL5 cell SOD entry 2140 (shown in FIG. 39A).The AAL5 rx slot may be either a small slot or a big slot. Similarly,for raw cells, the raw field 2198 is copied from the raw field 2152 inthe rx raw cell SOD entry 2144. When this bit is set, indicating thatthe slot is a raw cell slot, the second longword 2222 has nosignificance and is writte n with 0's by the SAR controller. The ownfield indicates whether the entry is owned by the adapter or by thehost. The polarity of the own bits is initially set to (1=owned by theSAR controller) after reset, and thereafter toggles every time the SARcontroller fills the rx report queue. This scheme is chosen to allow thedriver to determine ownership of a given entry in the queue withoutrequiring that the driver write to the queue. The slot tag fieldcontains the driver-generated slot tag which uniquely identifies the rxslot being reported. The driver uses this field to obtain the virtualaddress of the rx slot as previously described.

As the second longword of the rx AAL5 report queue entry is copied fromthe second longword of the rx AAL5 status report SOD entry 2160 (fromFIG. 39C), the fields included in word0 need not be described in anyfurther detail.

It is important to note that, after the driver initializes the rx reportqueue by writing the own bits in all the entries in the queue to 1, itnever writes the queue. Conversely, the SAR controller never reads therx status report queue.

When an AAL5 rx slot has been filled with data, the rx cell processor2057 creates an AAL5 status report SOD entry and places it in the rxdata FIFO, whether or not the slot is an end-of-packet rx slot. In fact,it is necessary to report all consumed AAL5 rx slots on receive (ascompared to reporting only EOP slots, as may be done in the transmitdirection), because these slots are shared among all open VCs.Therefore, the driver must be explicitly informed of the VC to whicheach rx slot has been allocated.

It may be recalled that, unlike AAL5 cells, rx slots for raw cells areconsumed at a rate of one rx slot per cell. Thus, to reduce the amountof bus bandwidth consumed by raw slots on receive, the driver can chooseto mitigate the rate at which raw cell status reports occur via a statusreport holdoff technique.

As shown in FIG. 42, a CSR indicated as a SAR_Cntrl2 register 2230provides an rx raw report holdoff (Rx_Raw_Report_Hldoff) field 2232 forspecifying a preselected rx raw report holdoff value N, corresponding toa number by which raw cell status reports may be prescaled. This valueis set by the driver. Also included in the SAR_Cntrl2 register 2230 areseveral other fields which pertain to the use of backward RM cells andcongestion handling. They include a slot_cong_CI_enb field 2233, abig_CI_enb field 2234, a small_CI_enb field 2235 and a raw_CI_enb field2236. The slot_cong_CI_enb field 2233 is set to enable the CI bit inturn-around RM cells when VC-specific slot congestion occurs. Thebig_CI_enb field 2234 is set to enable unconditional setting of the CIbit in turn around RM cells for VCs assigned to big slots. Thesmall_CI_enb field 2235 is set to enable unconditional setting of the CIbit in turn around RM cells for VCs assigned to small slots. Theraw_CI_enb field 2234 is set to enable unconditional setting of the CIbit in turn around RM cells for VCs assigned to raw slots. Furtherincluded are a big_slot_low_th field 2237, a small_slot_low_th field2238 and a raw_slot_low_th field 2239, each specifying an rx free slotFIFO threshold for a corresponding one of the rx free slot FIFOs atwhich an interrupt will be generated. The fields 2233-2239 will bediscussed in more detail later during a discussion of RM cell turnaroundand congestion handling mechanisms. Fields using remaining SAR_Cntrl2bits, indicated by 2240, are not pertinent to the description and thusomitted.

Returning to the consideration of rx raw cell status reports, therx_raw_report_hldoff (rx raw report holdoff) field 2232 is programmedwith N, where N is equal to the number of raw cell rx slots which mustbe filled with receive data before a raw cell status report isgenerated. In the illustrated embodiment, the rx raw report holdofffield 2232 is programmed with a two bit value, which can be decoded asfollows: ‘00’ specifies a report every raw rx slot, ‘01’ specifies areport every 4th raw rx slot, ‘10’ selecting a report every 16th raw rxslot and ‘11’ a report every 32nd raw rx slot. Thus, for a preselectedencoded value Y ‘10’, the SAR controller performs a single raw cellstatus report for every 16 rx raw cells received.

Referring to FIG. 35, the rx cell processor does not create a statusreport to report rx slot consumption for raw cells as it does for AAL5cells. Instead, the rx DMA engine 2082 detects that raw cell data (52byte raw cell and associated status information) is to be DMA'd into araw rx slot by reading the rx raw cell SOD entry 2144 (FIG. 39B) for therx request to be processed. If the raw field 2152 is set, the rx DMAengine copies the raw field and the slot_tag field 2182 (from the rx rawcell status longword 2148)—collectively referred to as rx raw reportholdoff information—into the rx raw report holdoff registers 2084. Theraw report holdoff registers 2084 are over-written with new data everytime a new raw rx cell is written to host memory by the rx DMA engine.The contents of the registers are DMA'd in a status report to the rxreport queue 38 (from FIG. 1) only when the rx request for the raw rxcell data is the Nth such request to be serviced.

Thus, the rx DMA engine 2082 employs the raw_rpt_hldoff (raw reportholdoff) counter/timer 2086 (shown in FIG. 35) as an event counter forcounting as events the processed rx requests for raw cell data. It isprogrammed to count a number corresponding to N. The count is modifiedin response to each transfer of raw cell data.

When implemented as a programmable downward counting counter, thecounter is initially loaded with a raw_rpt_hldoff (raw report holdoff)count corresponding to the value N (i.e., equal to the decoded value N)and decrements each time raw rx cell data is DMA'd into a raw rx slot.When the counter expires, the rx raw report holdoff information is DMA'dto the rx report queue 38 as an rx raw cell report queue entry 2224. Itmay be appreciated that the counter can also be an upward countingcounter, initialized to zero and incrementing upon each raw rx cell DMAuntil the counter expires, i.e., a count corresponding to N is reached.In fact, an device capable of detecting and signalling the occurrence ofN raw rx cell data transfers may be utilized. In yet anotherarrangement, the raw_rpt_hldoff counter/timer could be programmed totime a desired time interval between raw rx cell status report DMAs.

FIG. 43 depicts the method of adjusting or mitigating the frequency ofraw status report generation 2236 employed by the SAR controller inaccordance with the present invention. First, the rx raw report holdoffvalue N is selected 2242. Once N has been selected, the raw_rpt_hldoffcount corresponding to N is loaded into the raw_rpt_hldoff counter 2243.When a raw rx cell data transfer request is detected 2244, raw reportinformation—information necessary to create a raw rx cell statusreport—is copied into the raw report registers 2245. In this embodiment,the data transfer request is a DMA request and the raw reportinformation includes the slot_tag associated with the rx slot to befilled and the raw bit. Once the rx DMA engine has processed the rx rawcell DMA request by transferring the raw cell data to the host system2246, the raw_rpt_hldoff counter decrements by one 2248. If theraw_rpt_hldoff counter has expired 2250, the number of raw cellsprocessed by the rx DMA engine since the last raw cell status report DMAis equal to the rx raw report holdoff value N. Accordingly, the rawreport information in the raw report registers is DMA'd to the rx reportqueue 2252 and the process returns to step 2243. If the raw_rpt_hldoffcounter has not expired at step 2250, then the process returns to step2244.

Reporting raw cell slot consumption only on expiration of a an eventcounter or a timer means that not all consumed raw cell slots will bereported to the host system. Unlike AAL5 cell slots, raw cell slots areconsumed (filled with data) in the order in which they were posted bythe driver. Therefore, the the driver can easily ascertain which of theraw cell slots have been consumed whenever a new raw cell status reportappears in the rx report queue. To do so, driver must keep track of theslot tags and virtual addresses of raw cell slots, and the order inwhich the rx slots were pushed onto the rx raw free slot FIFO.Additionally, the VC of the cell with which each free slot is filledmust be extracted from the cell header. The mapped VC and other statusinformation for the raw cell may be extracted from the raw cell statuslongword DMA'd with the cell.

Generally, interrupts are generated following certain DMA operations;however, the rate at which this type of interrupt may occur may beadjusted, as discussed in further detail following the description ofthe receive operation.

Whenever the driver is interrupted, it processes outstanding rx reportqueue entries by grouping all AAL5 and raw cell rx slot tags together byVC. Any AAL5 end-of-packet indications signify that a complete AAL5packet has been received. Once the complete packet has been copied touser space or otherwise processed, all rx slots in which the packetresided may be reused.

RX Congestion Handling

When the SAR controller receives incoming rx cells, it writes the datain the rx cells into rx slots allocated via one of the three rx freeslot FIFOs, depending on the VC associated with the each of the rxcells, and on whether or not the rx cells are OAM F5 rx cells. Each ofthe three rx free slot FIFOs can hold a maximum of 1K entries in 1K-VCmode. As an rx slot corresponding to one of the free slot FIFOs isfilled with data and its consumption reported to the host system throughthe rx report queue in host memory, the host system copies the data fromthe rx slot and reposts the rx slot to the free slot FIFO to which thereposted rx slot corresponds. Unfortunately, the host system usuallyempties and reposts rx slots on packet boundaries only. For raw cellslots, a “packet boundary” occurs at every rx slot. For AAL5 rx slots,packet boundaries occur every N rx slots, where N may be arbitrarilylarge, depending on the size of the incoming packets and the size of therx slots. If many VCs are active simultaneously, with a high degree ofinterleaving on the physical link, and the packets being received arelarge in comparison to the size of the rx slots (such that a singlepacket occupies many slots), then one of the rx AAL5 free slot FIFOs maybe depleted of slots. It is assumed that this situation would neveroccur with raw cell rx slots, which may be reclaimed by the host andre-posted to the free slot FIFO on a slot-by-slot basis.

The condition in which one or both of the rx AAL5 free slot FIFOs arebecoming empty (less than 10% full, for example) is termed rxcongestion. If either of the rx AAL5 free slot FIFOs (i.e., the big orsmall rx free slot FIFO) becomes completely empty, slot exhaustion issaid to have occurred. If all of the rx slots from the rx AAL5 free slotFIFOs are occupied with partially assembled packets, then reassemblydeadlock has occurred. At this point, one or more packets must bedropped as quickly and efficiently as possible, in order to reuse the rxslots occupied by those packets in order to complete reassembly on otherpackets.

The SAR controller implements a simple algorithm to avoid or minimize rxcongestion. Again referring to FIG. 37, the slots_consumed (slotsconsumed) counter 2112, implemented as an 8-bit upward counting counter,is kept in each rx VC state table entry 2070 in the rx VC state table150. Thus, each flow (e.g., VC) has an associated slots_consumedcounter. Each slots_consumed counter 2112 is initialized to 0 by thedriver at initialization time. Whenever a new rx slot is taken from oneof the rx free slot FIFOs, the slots_consumed counter 2112 associatedwith the VC of the data to be placed in the rx slot is incremented by 1.Whenever the rx slot is returned to a corresponding one of the free slotFIFOs by the host system, the associated slots_consumed counter isdecremented by 1. (Recall that the host reposts an rx slot to one of thefree slot FIFOs by writing the address of the rx slot followed by a VC).It should be noted that the slots_consumed counters stick at 0 duringdecrementing, so any value may be written to the VC field of a write tothe rx pending slot address spaces at initialization time (when all therx_slots_consumed counters will be 0). It can be understood that theslots_consumed counter may be implemented as a downward counting counteras well.

FIG. 44 illustrates the layout of an rx_slot_cong_th register (CSR) 2254utilized by the rx congestion handling mechanism. The rx_slot_cong_thregister 2254 stores three predetermined rx_congestion_threshold (orpredetermined congestion threshold) values, each associated with adifferent one of the supported slot types. As already noted, each of thethree free slot FIFOs corresponds to a different one of the slot types.Each predetermined rx congestion threshold is therefore associated witha free slot FIFO via the slot type to which the free slot FIFOcorresponds. The predetermined rx congestion threshold values arewritten by the host system. As shown in the figure, the rx_slot_cong_thregister 2254 includes a raw slot_cong_th (raw slot congestionthreshold) field 2256 for indicating the threshold value associated withthe raw free slot FIFO. This field specifies the number of raw slotswhich a single VC may be allowed to consume before it is consideredcongested. Further included in the rx_slot_cong_th register 2254 is abig_slot_cong_th (big slot congestion threshold) field 2258 forindicating the threshold value associated with the big free slot FIFOand a small_slot_cong_th (small slot congestion threshold) field 2260for indicating the threshold value associated with the small free slotFIFO. The big_slot_cong_th field 2258 specifies the number of big slotsthat a single VC may be allowed to consume before it is consideredcongested. The small_slot_cong_th field 2260 specifies the number ofsmall slots that a single VC may be allowed to consume before it isconsidered congested. A value of 0 in any of the three fields disablesthe congestion detection and reporting mechanism. Lastly, the MSB in theregister is a reserved space, indicated by reference number 2262. Thus,the three threshold values are FIFO-specific, but used across all VCs.

FIG. 45 depicts an rx congestion control method 2264. At initializationtime, the driver sets or initializes the slots_consumed counters tozero. For an incoming rx cell received from the network, a determinationis made as to which rx slot (if any) is allocated to receive this data2266. It should be noted that this method, which addresses the problemof congestion, concerns the type of rx cell which uses an rx slot.Typically, rx cell types such as null cells, unopened- or unknown-VCcells, as well as some types of RM cells, are dropped. Returning to themethod, the slot type is obtained from the rx VC state table entrycorresponding to the VC on which the incoming rx cell is being carried2268. The slot type indicates a corresponding one of the rx free slotFIFOs (the selected rx free slot FIFO) to be used for rx slotallocation. If an rx slot has already been allocated, the slot type isused to determine whether or not the rx slot has enough space availableto receive the data. If the allocation of an rx slot is necessary 2269,the slots_consumed counter associated with the VC on which the rx cellis received is compared to the rx congestion threshold value associatedwith the slot type to which the free slot FIFO from which the new rxslot is to be taken 2270 corresponds. In a system which supportscredit-based flow control, the method will determine if the VC iscredit-based flow control enabled 2271. If it is not, and the VC is atthreshold at this time (i.e., the slots_consumed counter is equal to therx_congestion_threshold) 2272, the new rx cell is dropped 2274. Itshould be noted that, with brief reference to FIG. 39, the SARcontroller sets the congestion flag 2104 in the rx VC state table entry2070 when the VC is at threshold. The congestion flag is utilized toindicate congestion on RM cell turnaround, as later discussed.

When the SAR controller drops an rx cell for an AAL5 VC, it continues todrop cells (even if the VC becomes uncontested) until the next AAL5packet boundary. Returning to FIG. 47, congestion detected on the VC isreported as soon as possible (at the next status report time) by settingthe appropriate bit in the status field of the rx AAL5 report queueentry 2275. When the host system processes the report queue entry andsees that congestion on the VC has occurred, it knows that the VC hastoo many slots outstanding. In response, the host system discards thepacket in which the status field bit is set, and reposts (via the rxslot descriptor, which indicates the VC with which the returned rx slotsare associated) the outstanding rx slots to the appropriate rx free slotbuffer as soon as possible 2276. Thus, the step of repasting the rx slotinvolves both returning the rx and indicating a VC as discussed.Repasting the rx slots will cause the slots_consumed counter todecrement for each rx slot returned 2277. If the counter falls below therx congestion threshold 2278, the VC is able to start receiving dataagain through the allocation of a new rx slot.

If the VC is not at the threshold at step 2272, then the rx slot isallocated from the corresponding (or selected) free slot FIFO 2277 andthe associated slots_consumed counter is incremented by one 2278. The rxcell is processed by the rx cell processor and then DMA'd as processedto the rx slot by the rx DMA engine 2279. The step of processing the rxcell in this context and embodiment refers to the activities performedby the rx cell manager in preparing and writing the rx cell data alongwith associated SOD entries to the rx data FIFO as discussed earlier. Ina general sense, it refers to any functions that may be performed inpreparing and submitting the rx cell data to an rx data buffer afterslot allocation has occurred and is not limited to a particular mannerin which they are performed. Once the host system has recovered the rxslot, the freed rx slot is reposted to the corresponding free slot FIFO(the free slot FIFO from which it was taken) 2280 and the slots_consumedcounter for the VC is decremented by one 2281.

Returning to step 2271, if the VC is enabled to be a credit-based flowcontrol VC, and the counter is greater than or equal to the thresholdvalue 2282, credit return for the VC is deferred until theslots_consumed counter drops below the associated predeterminedcongestion threshold value 2283. Typically, the SAR controller keeps aper-VC count of the credits pending return to a given VC. If the VC isalready below threshold, then a credit is returned 2284.

The above-described mechanism thus ensures that a single or a fewmisbehaving VCs (which are either being serviced too slowly by the hostsystem or which are carrying packets relatively large in comparison tothe rx slot sizes) do not impact reassembly of more well-behaved VCs byconsuming more than their fair share of “free” rx slots.

Even with the above mechanism, it is still possible for the SARcontroller to encounter slot exhaustion and/or reassembly deadlock. Forexample, even if rx_congestion_threshold for a given rx free slot FIFOis set to a small value, such as 8, for 1K slots, as few as 128 VCs maystill consume all available rx slots. Another mechanism is thereforeprovided to deal with this problem.

When the reception of a new rx cell requires that a new slot from one ofthe free slot FIFOs be taken, leaving that rx free slot FIFO empty, therx cell is discarded and an interrupt request generated via interruptblock 96 (FIG. 3). For AAL5 slots, the rest of the packet to which thecell belonged is also discarded. No attempt is made to report the VCwhich caused the exhaustion of slots, since no VC is directly at fault(unless that VC is above the congestion_threshold for the free slot FIFOwhich it is using, in which case a status report for the VC willeventually indicate the condition).

Similarly, an interrupt request may be generated when the rx free slotfrom which a new slot has been allocated reaches a “low” threshold.Referring back to FIG. 41, the low thresholds for raw, small and big rxslots are contained in the SAR_Cntrl2 register 2230 in theraw_slot_low_th field 2237, the small_slot_low_th field 2238 and thebig_slot_low_th field 2239, respectively. Each of these fields specifiesthe FIFO level (number of rx slots remaining) at which an interruptrequest will be generated for the free slot FIFO to which itcorresponds. In the embodiment described herein, the bits in thesefields are decoded as follows: ‘00’ indicates 8 slots, ‘01’ indicated 16slots, ‘10’ indicates 32 slots and ‘11’ indicates 64 slots.

These schemes do not attempt to differentiate between “important” VCsand “less important” VCs when dropping cells due to congestion. Instead,they report to the host system all VCs on which data was lost due tocongestion whenever possible. It is then the responsibility of the hostsystem to respond to the situation. For example, the host system mayreduce the number of VCs active at one time, increase the rate at whichit services receive traffic (if response time is the problem) orincrease the size of the rx slots. Finally, it should be noted thatthere is no way for the host system to determine which VCs have lostdata due to slot exhaustion.

AAL5 Reassembly Timeout

It is not guaranteed that every received AAL5 packet for which the SARcontroller begins reassembly is completed. For example, if the cellcontaining the EOM bit for a packet on a given VC is lost due to datacorruption by the network, reassembly of the packet will not completeuntil a subsequent packet is received on the VC. If no other packet isreceived on the VC for a long period of time, the rx slots being used toreassemble the first packet will go unrecovered for this time period,wasting host memory.

The SAR controller provides the capability to detect when no cells foran AAL5 packet being reassembled have been received for a programmableperiod of time. When this occurs, the packet will be “timed-out”, theremainder of it (if received) will be dropped, and the event will bereported to the host through an rx status report.

A single global (across all VCs) reassembly timeout time may bespecified through the Rx_RATO_Time field of the SAR_Cntrl2 register inCSRs. This field is 4-bits wide, and provides for timeout times in therange of 386 ms-2.895 s±193 ms. If the field is written with a 0, thetimeout function for AAL5 packets is disabled. The OAM F5 cells receivedon a given VC are not considered part of an AAL5 packet beingreassembled on the VC for purposes of reassembly timeout.

Interrupts

Overall interrupt control is provided by the interrupt block 96 (shownin FIG. 4). As shown in FIG. 46, the INT CSRs 92 include an interruptstatus (Intr_Status) register 2300, which is used to indicate interruptrequests for supported interrupt sources. In the embodiment shown, eachbit in the interrupt status register 2300 corresponds to a singleinterrupt source. When an interrupt event occurs, the bit correspondingto the appropriate interrupt source for the interrupt event in theinterrupt status register is set by the SAR controller to indicate aninterrupt request by the corresponding interrupt source. When the driverwrites a one to the bit, interrupt signaling is prevented. A driverwrite of 0 to the bit will not modify its state.

Referring to FIG. 46, the INT CSRs further include an interrupt enableregister (Intr_Enb) 2302. The interrupt enable register allows each ofthe interrupt sources in the interrupt status register to be selectivelyenabled or disabled. When any bit in the interrupt status register 2300is set, an interrupt request can be generated on the system bus only ifa corresponding bit in the interrupt enable register 2302 is set. If thecorresponding bit in the interrupt enable register 2302 is cleared, nointerrupt request will be generated even though the interrupt status bitmay be set. Consequently, the driver may determine that an interruptevent has occurred by reading the interrupt status register 2300 even ifthe interrupt enable bit for the interrupt event has been cleared andthe interrupt therefore disabled.

Interrupt status register 2300 includes several fields corresponding tocongestion-related interrupt events. As shown, there is provided anrx_no_big_slots field 2304, an rx no_small_slots field 2305 and an rxno_raw_slots field 2306. The rx_no_big_slots field 2304 indicates thatthe rx big free slot FIFO is empty. This interrupt request is generatedon reception of an rx cell which causes the FIFO to become empty and onreception of every rx cell for a big slot while the FIFO remains empty.The rx_no_small_slots field 2305 indicates that the rx small free slotFIFO is empty. This interrupt request is generated on reception of an rxcell which causes the FIFO to become empty and on reception of every rxcell for a small slot while the FIFO remains empty. The rx_no_raw_slotsfield 2306 indicates that the rx raw free slot FIFO is empty. Thisinterrupt request is generated on reception of an rx cell which causesthe FIFO to become empty and on reception of every rx cell for a rawslot while the FIFO remains empty.

Also included are rx_big_slots_low field 2307, rx_small_slots_low field2308 and rx_raw_slots_low field 2309. These low threshold fields areassociated with the rx big free slot FIFO, the rx small free slot FIFOand the rx raw free slot FIFO, respectively. For the free slot FIFO withwhich it is associated, each indicates that the FIFO has less than Nslots available. The value of N is specified in the SAR_Cntrl2 register2230 (FIG. 42). For the rx big free slot FIFO, it is provided by thebig_slot_low th field 2237. For rx small and raw free slot FIFOs, N isspecified by the small_slot_low_th field 2238 and theraw_slot_low_th_field 2239, respectively. When bits in these fields areset, an interrupt request is generated provided that a corresponding bitin the interrupt enable register is set. Rx_no_bit_slots_En field 2310corresponds to 2303. Rx_no_small_slots_En field 2311 corresponds to2304. Rx_no_raw_slots_En field 2312 corresponds to 2305. For the lowthreshold interrupts, an rx_big_slots_low_En field 2313, anrx_small_slots_low_En field 2314 and an rx_raw_slots_low_En field 2314correspond to fields 2306-2309 in the interrupt status register 2300.

IOC Interrupts

There is one class of interrupt sources or interrupts available in theinterrupt status register 2300 which is treated differently from otherinterrupt sources. Referring again to FIG. 46, that class is the IOC(Interrupt-On-Completion) class of interrupts and includes a tx_IOCinterrupt 2316 and an rx_IOC interrupt 2317. Interrupt fields 2318correspond to other types of interrupts not pertinent to anunderstanding of IOC interrupt request generation and thus not describedherein. As mentioned above, each of these interrupts, tx_IOC and rx_IOC,has a corresponding mask bit interrupt enable register like all otherinterrupt sources. Shown in the interrupt enable register 2302 in FIG.46 are a tx_IOC_en 2319 and an rx_IOC_en 2320 corresponding to thetx_IOC interrupt 2316 and the rx_IOC interrupt 2317, respectively.Enable fields 2321 corresponding to the interrupt fields represented by2318, are not shown or discussed.

Unlike the other interrupt sources, the rate at which the Tx_IOC and theRx_IOC interrupts are generated can be controlled by the driver. Asshown in FIG. 46, an interrupt holdoff (Intr_Hldoff) register 2322provides an additional level of interrupt control in the form of holdoffcapability, which is both time and event-based. The holdoff capabilityfrees up the host system, while ensuring that the host system willservice interrupt requests when either a given period of time haselapsed or a given number of interrupt events has occurred.

As shown in FIG. 46, holdoff parameters are provided by a Tx_IOC_Hldoff(or tx IOC holdoff) timer 2323, which defines a tx_IOC holdoff interval(or tx IOC holdoff event-based count), the amount of time which mustelapse since this field was last written before an interrupt request tothe host system may occur. The tx_IOC holdoff interval may be programmedin the range 0-128 ms, in units of 503.04 μs, for this embodiment. AnRx_IOC_Hldoff (or rx holdoff) timer 2324 defines an rx_IOC holdoffinterval, the amount of time which must elapse since this field was lastwritten before an rx_IOC interrupt may be generated to the host system.In this embodiment, the rx_IOC holdoff interval may be programmed in therange 0-1 ms, in units of 3.93 μs.

Also provided is a Tx_IOC_hldoff (or tx IOC holdoff) event counter 2325,which may be programmed to count a tx_IOC event count, i.e., defined tocount a number of events, in the range 0-127. An Tx_IOC “event” is thedata transfer, a DMA in this embodiment, of any of the following: datafrom a tx EOP raw slot; data from a tx AAL5 slot for a streaming modeVC; data from a tx EOP AAL5 slot. The holdoff event counter is modifiedby one every time such a tx_IOC event occurs. In the preferredembodiment, it is a downward counting counter. Every time a tx_IOC eventoccurs, the tx_IOC_hldoff event counter 2325 decrements by 1.Alternatively, the counter could be implemented as an upward countingcounter which increments upon the occurrence of a tx_IOC event. When thetx IOC holdoff event counter has “expired”, i.e., counted (eitherupwardly or downwardly) a number of events equal to the tx_IOC eventcount, an interrupt request may be generated to the host system.

For a receive operation, there is provided an rx_IOC_Hldoff (or rx IOCholdoff) event counter 2326, which may be programmed to count an rx_IOCevent count in the range 0-127. An Rx_IOC “event” is the receipt of asingle rx raw cell, the consumption of an rx AAL5 EOP slot for astreaming mode VC, or the reception of a complete rx AAL5 packet. Everytime an Rx_IOC event occurs, the rx_IOC_hldoff event counter 2326 ismodified by one. In the preferred embodiment, the holdoff event counteris a downward counting counter which decrements each time an rx_IOCevent occurs. Alternatively, this counter could be implemented as anupward counting counter which increments upon the occurrence of anrx_IOC event. When the rx_IOC_hldoff event counter 2326 has expired,i.e., counted (either upwardly or downwardly) a number of events equalto the rx_IOC event count, an interrupt request may be generated to thehost system. Therefore, when either a holdoff timer or event counterrequirement is satisfied for a given IOC interrupt, an interrupt requestmay be generated to the host system via the system bus.

The counting logic implementing the event counter or timer functions iswell known and thus not described. The counters and timers must beretriggered once an interrupt request has been sent and serviced. Inthis embodiment, the timers and event counters are not of theself-triggering variety. Once they have expired, they must be re-loadedby the driver with new holdoff parameters (i.e., a new count or holdoffinterval) as appropriate. The new parameters may be the same values asthe previous parameters or may be new values to reflect anotheradjustment deemed necessary to improve the efficiency of host systemutilization.

It is important to understand that receive raw cells are counted by theRx_IOC_Hldoff event counter whether or not they result in statusreports. Accordingly, the Rx_IOC_Hldoff event counter should beprogrammed with a count greater than or equal to that specified by theRx_Raw_Report_Holdoff field to minimize spurious interrupts.

Still referring to FIG. 46, an rx_IOC_hldoff_wr field 2328 and atx_IOC_hldoff_wr field 2330 control whether or not the rx_IOC and tx_IOCholdoff parameters, respectively, may be written. These fields must beset to 1 to enable a write of the corresponding holdoff parameters.

Referring now to FIG. 47, there is shown a flow diagram depicting oneembodiment of the interrupt frequency mitigation method 2340 inaccordance with the present invention. The method proceeds withreference to either a transmit or receive operation, so “IOC” representseither “rx_IOC” or “tx_IOC”, “holdoff” is either “rx IOC holdoff” or “txIOC holdoff”). Further, although “DMA” is described, any type of datatransfer can be used. At step 2342, a DMA operation is performed. Afterdata has been DMA'd, the SAR controller determines whether the DMAoperation is an IOC event 2344. Note that this is performed by the txdata DMA FSM in the transmit direction and the rx DMA engine in thereceive direction. These units will read the INT field in the DMArequest to determine if the Int bit is set, or, in the case of raw rxcells, the rx DMA engine reads the RAW bit to determine if a raw cellDMA request is being serviced. If the DMA operation qualifies as an IOCevent at step 2344, the IOC bit is set 2346 (i.e., the rx DMA enginesets the Rx_IOC bit or the tx data DMA FSM sets the tx_IOC bit) and theholdoff event counter for the IOC is decremented 2348. If the holdoffevent counter expires 2350 as a result of step 2348, and the IOCinterrupt is enabled 2352 as indicated by the setting of the IOC_enfield by the driver, the interrupt logic causes the assertion of aninterrupt request to the host system 2354, which processes the IOCinterrupt request 2356. Once the host system has processed the IOCinterrupt request, it clears the IOC bit. Lastly, the holdoff timer andevent counters are retriggered 2358, and the method subsequently returnsto step 2342. If the IOC interrupt is not enabled at step 2352, then theIOC interrupt request is masked off 2360 and the process goes to step2342. Returning to step 2350, if the holdoff event counter has notreached zero, but the holdoff timer for timeout has expired 2362, themethod performs the step 2352 as described above. If the holdoff timerhas not yet reached zero at step 2362, step 2360 is performed asabove-described. If the DMA operation is not an IOC event at step 2344,the method goes directly to step 2342 as described above.

The interrupt generation “path” 2364 is illustrated in the block diagramof FIG. 48. As shown, the interrupt block 96 has a number of data andaddresses lines, as well as controls signals by which the driver can setand read the INT CSRs via the PCI bus interface. These lines areindicated by 2366. Additional inputs are received from the tx data DMAFSM and the rx DMA engine. Via signals tx_IOC_int 2368, the tx data DMAFSM can assert the tx_IOC interrupt request and decrement thetx_IOC_hldoff event counter as needed. Via signals rx_IOC_req 2372 andrx_IOC_dec 2374, the rx DMA engine can assert the rx_IOC interruptrequest and decrement the rx_IOC_hldoff event counter, respectively. Theinterrupt logic 94 is coupled to the INT CSRs 92 and serves to assertthe int_req signal 2380 to the PCI bus interface 78, which in turnasserts low an interrupt request signal, INTA 2382, one of the PCIbus-defined interrupt requests, on the PCI bus 18 during a transmitoperation when a) either the tx_IOC_hldoff timer or tx_IOC_hldoff eventcounter has timed out and thus asserted a timeout signal to the INTlogic; b) the tx_IOC interrupt bit is set; and c) the correspondingtx_IOC_en bit is set. If any of the three conditions (a)-(c) is not met,intr_req is masked off and the INTA interrupt request is not asserted.If all of the three conditions is met, INTA interrupt request isasserted. Similarly, the INT logic 94 asserts the int_req signal to thePCI bus interface, which asserts INTA, during a receive operation whena) either the rx_IOC_hldoff timer or rx_IOC_hldoff event counter hastimed out and thus asserted a timeout signal to the INT logic; b) therx_IOC interrupt bit is set; and c) the corresponding rx_IOC_en bit isset. If any of the three conditions in not met, the INTA interruptrequest is not asserted. The assertion of INTA on the PCI bus indicatesto the host that the adapter is requesting an interrupt from the host.Once the INTA signal is asserted, it remains asserted until the driverclears the pending request. When the request is cleared, the SARcontroller deasserts the INTA signal.

Although the above interrupt frequency mitigation is described withrespect to IOC interrupts, it need not be so limited. It can be appliedto any type of interrupt.

It can be seen from the foregoing that the interrupt frequencymitigation functions in manner that is responsive to both latency andworkload concerns. The holdoff event counter enables the host system tooperate more efficiently by mitigating the frequency of interruptswithout allowing the host system to fall too far behind in its work. Theholdoff timer also mitigates the rate at which interrupts may occur, butserves to bound the latency associated with the processing of reports.Thus, a balance that is both time- and event-sensitive is achieved.

It can be further seen that the mitigation of the frequency of tx rawcell status reports and interrupts may be combined. For example, if a txraw cell status report is allowed to occur only every N raw cell rxslots, then that status report is counted as an interrupt event, or moreparticularly, a tx IOC event, and an interrupt request is generated forevery X events (or X*N raw cell rx slots).

In reference to the above description, it can be understood that thenetwork node operates in a manner that obviates the need for controlreads on the system bus for the normal flow of data in both the transmitand receive directions. The host system writes control information inthe form of tx and rx slot descriptors to the adapter. The adapterwrites control information in the form of status reports to the host.Therefore, by reducing the system bus bandwidth ordinarily consumed bycontrol reads, overall throughput is greatly improved. In the event thatan exception condition occurs, the host system may need to read theCSRs. Because interrupt rates can be mitigated, however, this type ofcontrol read should be fairly infrequent.

This control read avoidance mechanism need not be limited to an ATMnetwork node or even a network node. Alternative system configurationsand system operations embodying the mechanism are suggested by the blockdiagram shown in FIG. 49, which depicts the system 10 having the hostsystem 14 connected to the system bus 18 as shown in FIG. 1. Here, thehost system 14 includes, in relevant part, the CPU 20 coupled to thehost memory 22, and the host memory includes the driver 24 and a datamemory 2400. The data memory is divided into memory portions 2404 (e.g.,blocks) of the same or varying sizes and may be used to store outgoingand incoming data. Also connected to the system bus 18 in thisalternative system configuration is an interface 2406, which couples thehost system 14 as shown in FIG. 49 to a peripheral unit 2408. Theinterface includes a controller 2410, an interface (I/F) buffer memory2412 and an interface (I/F) control memory 2414. The controller isconnected to both the I/F buffer memory and the I/F control memory. TheI/F control memory includes a number of locations corresponding to andstoring control information in the form of control attributes data 2413written by the host system to the interface.

The data memory stores data to be transferred to the interface by thehost system. The driver 24 writes to the interface 2406 via the systembus 18 the control information or control attributes data 2413corresponding to each data memory portion 2404 occupied by data in thehost memory, each of the control attributes data being placed in aseparate one of the locations in the I/F control memory 2414. Thecontrol attributes data may include starting addresses associated withthe data memory portion to which the control attributes datacorresponds. The controller 2410 reads the control attributes dataassociated with the data to be read from the host system, then copiesand processes the data according to the control attributes data.

The interface 2406 is intended to represent any number of interfaceswhich typically require the transfer of control information during adata transfer operation. Similarly, the peripheral unit 2408 is intendedto represent any type of peripheral unit being served by such aninterface.

By way of an example, the interface 2406 may be a video adapter and theperipheral unit 2408 a display memory. In this type of a system, thedata memory may serve as a screen memory for storing character codes tobe read by the controller on the video adapter. The control attributesdata written by the host system to the I/F control memory may includecharacter attributes data needed by the controller 2410 in processingthe character code.

Alternatively, the interface 2406 could also be a mass storage systemadapter and the peripheral unit 2408 a mass storage system. In thisexample, the control attributes data 2416 might include addresses andother types of control information data, e.g., metadata. Unlike thevideo system, the host system in this example would write the interfacewith such control information corresponding to data memory portionsholding data to be transferred to the adapter or data memory portions toreceive data from the interface, where the interface has received datafrom the mass storage system to be transferred to the microprocessorsystem.

In yet another alternative, the peripheral unit 2408 is a network busand the interface 2406 a network adapter. The operation of this systemis similar to the previous example in that the host system is alsoproviding the interface with control information associated with thedata memory portions to receive incoming data. In this type ofembodiment, however, the incoming and outgoing data is packet data.

Backward RM Cells

The ATM Forum Traffic Management Specification specifies RM cells usedfor ABR flow control. Following the ATM header as shown in FIG. 2, an RMcell has a message type field 2417 as shown in FIG. 50. Included in thismessage type field is a congestion indication (CI) bit 2418. The CI bitis set to cause the sourc e of an RM cell to decrease the ACR for the Vcwith which the RM cell is associated. In compliance with the ATM ForumTraffic Management Specification, the CI bit is to be handled in thefollowing manner for backwards RM cells:

1) when a data cell is received on a VC, its EFCI indicator is saved asthe EFCI state for that VC. Whenever the EFCI state for a VC is set, thebackward RM cell should be sent with its CI bit set (=1). The EFCI statefor the VC should then be reset.

2) when a forward RM cell is received, the cell is returned (“turnedaround”) to the source by sending a backward RM cell. The CI field, ifset, is to remain unchanged.

3) When internal congestion is detected at a node (i.e. an adapter),that node may set the CI bit in any backward RM cells sent.

Referring now to FIG. 51, there is shown a logical representation of thefunction undertaken by the RM cell request generator 435 portion of thetx rate scheduler 120 to generate the CI bit for a backward RM cell.Accordingly, the CI bit in a backward RM cell is set when the signalBRM_CI is set. This signal is set when either the CI_TA bit is set,indicating the receipt of a forward RM cell with its CI bit set (point 2above), or when the EFCI bit is set, indicating reception of a data cellwith its EFCI bit set (point 1 above), or when an application specificCI bit AP_CI is set (‘or’ gate 2420). The AP_CI bit is set when internalcongestion has been detected by the SAR controller 62 (point 3 above).

Internal congestion is indicated on either a VC specific basis or on areceive slot type basis. First of all, recall that a VC_congestion bit2104 is set in rx VC state for a VC when it is determined that the givenVC has consumed receive slots beyond a threshold value (FIG. 37).Referring now to FIG. 42, the control register 2230 shown contains aslot_cong_CI_enb bit 2233. This bit is set by the driver 24 when it isdesirable to indicate congestion on a per-VC basis; i.e. when aparticular VC has consumed receive slots beyond a threshold value. Whenthe slot_cong_CI_enb bit is set, and when the congestion bit for a givenVC is set in rx VC state for the VC, a CI_VC bit is set (‘and’ function2422) which causes in turn the assertion of the AP_CI bit (‘or’ function2424), and thus the assertion of the BRM_CI bit. Thus, any backward RMcell sent on that VC will be sent with its CI bit set.

Second of all, the control register 2230 includes Raw_CI_enb 2236,Big_CI_enb 2234, and Small_CI_enb 2235 bits which can be set by thedriver 24. In the event that any of these bits is set when an RM cell isreceived and associated with the corresponding slot type, a slot_type_CIbit is set (mux function 2426), causing the AP_CI bit to be asserted.Backward RM cells for all VCs associated with receive slots of that typeare then sent with their CI bits set.

This functionality can be useful, for example, when the driver detectsthat the small_slot_low_th bit in the register 2230 has been set by thereassembly engine 90. In this case, the driver can choose to set theSmall_CI bit in the control register 2230. All RM cells thereafterreceived on VCs associated with small receive slots will then be turnedaround and transmitted with their CI bits set, thereby easing congestionin the small receive slots.

Referring back to FIG. 35, rx cell manager 2055 generates the BRM_CI bitas previously described, making it available along with other BRM cellheader fields in the local memory 76 to be accessed by the tx cell FSM130 when building an RM cell header (FIG. 28c steps 902-916).

Note that the technique previously described can be useful in a generalway as applied to connection-oriented networks employing congestioncontrol schemes, such as forward explicit congestion notification (FECN)or backward explicit congestion notification (BECN) schemes. In general,where there are provided slots for receiving data units, a slot_typecongestion signal is generated for indicating that the number of slotsavailable for receiving data units is below a threshold limit. A CI_VCsignal is further generated for indicating that the buffer spaceconsumed by cells received on a particular virtual circuit (VC) haspassed a threshold value. A congestion indication bit in a data unit tobe transmitted when either the slot_type congestion signal or the CI_VCsignals are asserted.

It is apparent that within the scope of the invention, modifications anddifferent arrangements may be made other than as disclosed herein. Thepresent disclosure is merely illustrious, the invention comprehendingall variations thereof.

What is claimed is:
 1. A method for reporting information in a networknode having a host system including a host memory coupled to a networkby an adapter, the adapter reassembling cell data received from thenetwork and storing the reassembled cell data in the host memory,comprising the steps of: allocating, in the host system, plural slotsinto which received data is transferred, a slot being a physicallycontiguous area of host memory, each slot being of one of a plurality ofsizes, a raw cell consuming exactly one rx raw cell slot, a rx raw cellslot being at least large enough to hold an entire raw cell; detecting,in the adapter, a raw cell data transfer request; transferring, uponsaid request, the raw cell data from the adapter to an rx raw cell slotin the host system, rx raw cell slots being consumed in the order inwhich they are posted; deciding, in the adapter, whether to send a rxraw cell status report to the host system; and upon a decision to send arx raw cell status report, creating a rx raw cell status report whichexplicitly identifies the rx raw cell slot to which the raw cell datawas transferred, said rx raw cell status report implicitly identifyingrx raw cell slots to which raw cell data has been transferred since thelast rx raw cell status report sent to the host system, and transferringthe created rx raw cell status report from the adapter to the hostsystem, thereby mitigating the number rx raw cell status reports neededto be transferred to the host system.
 2. The method of claim 1, furthercomprising the steps of: programming a rx raw report holdoff counter tocount a predetermined value; upon transferring raw cell data, modifyingthe counter; and only when the modified counter has expired,transferring the rx raw cell status report, and reprogramming thecounter to count the predetermined value.
 3. A method of reportinginformation in a network node having a network and a host systemincluding a host memory coupled to the network by an adapter accordingto claim 2, wherein the data transfer is a data DMA operation.
 4. Amethod of reporting information in a network node having a host systemincluding a host memory coupled to a network by an adapter acccording toclaim 2, wherein the rx raw report holdoff counter is a downwardcounting counter and the step of modifying causes the rx raw reportholdoff counter to be decremented.
 5. A method of reporting informationin a network node having a host system including a host memory coupledto a network by an adapter acccording to claim 2, wherein the rx rawreport holdoff counter is an upward counting counter and the step ofmodifying causes the rx raw report holdoff counter to be incremented. 6.The method of claim 1, further comprising the steps of: programming atimer to time a predetermined interval; and only when the timer hasexpired, transferring the last rx raw report information, andreprogramming and the timer to time the predetermined interval.
 7. Anapparatus for reporting information in a network node having a hostsystem including a host memory coupled to a network by an adapter, theadapter reassembling cell data received from the network and storing thereassembled cell data in the host memory, comprising: means forallocating, in the host system, plural slots into which received data istransferred, a slot being a physically contiguous area of host memory,each slot being of one of a plurality of sizes, a raw cell consumingexactly one rx raw cell slot, a rx raw cell slot being at least largeenough to hold an entire raw cell; means for detecting, in the adapter,a raw cell data transfer request; means, coupled to the detecting means,for transferring the raw cell data from the adapter to an rx raw cellslot in the host system, rx raw cell slots being consumed in the orderin which they are posted; means, coupled to the detecting means, fordeciding, in the adapter, whether to send a rx raw cell status report tothe host system; means for creating, upon a decision to send a rx rawcell status report, a rx raw cell status report which explicitlyidentifies the rx raw cell slot to which the raw cell data wastransferred, said rx raw cell status report implicitly identifying rxraw cell slots to which raw cell data has been transferred since thelast rx raw cell status report sent to the host system; and means fortransferring the created rx raw cell status report from the adapter tothe host system, thereby mitigating the number rx raw cell statusreports needed to be transferred to the host system.
 8. An apparatus forreporting information in a network node having a host system including ahost memory coupled to a network by an adapter according to claim 7,wherein the means for determining is an upward counting counter forcounting up to a number corresponding to the preselected rx raw reportholdoff value, the counter being initialized to zero and incremented inresponse to each data transfer of raw cell data.
 9. An apparatus forreporting information in a network node having a host system including ahost memory coupled to a network by an adapter according to claim 7,wherein the means for determining is a downward counting counter beingset to an initial count corresponding to the preselected rx raw reportholdoff value, the downward counter decrementing in response to eachdata transfer of raw cell data.